freenode/#lisp - IRC Chatlog
Search
5:51:00
madrik
Out of curiosity, I know that popular Lisp systems currently feature a compiler as given, with an optional interpreter. Are there any systems with _only_ a Common Lisp interpreter?
5:53:57
edgar-rft
madrik: https://almy.us/xlisp.html is the only one I know, but it's not a full implementation of Common Lisp
11:48:38
p_l
madrik: some systems can be run with just evaluator, but Common Lisp requires "minimal compilation" (expansion of macros etc.)
11:49:11
p_l
technically some implementations skirt this literally but preserve the required semantics, like LW which uses evaluator when tracing macros
13:39:41
beach
no-defun-allowed: The default would be to create a method like (defmethod some-reader ((x some-class)) (slot-value x 'the-slot-name)), but there are ways of making it faster. When the effective method is created, it is often possible to use standard-instance-access instead, which is much faster.
17:03:52
hsaziz
After removing a distro installed version of SLIME, my MELPA (stable) installed SLIME version still insists on accessing the old system wide swank-loader.lisp.
17:14:29
pjb
MacLISP forked in 1966 from LISP 1.5. So it probably included macro from the start. Perhaps it was the first one to have macros exactly like our defmacro. I've not read the AIM 57 yet, but it looks like they hacked macros over FEXPRs…
17:18:42
_death
don't use melpa for slime.. quicklisp-slime-helper is acceptable, or clone the repo and config yourself
17:20:20
madrik
_death: Should we not use either MELPA or the distribution's repositories in any circumstance?
17:22:57
phoe
for slime use either (ql:quickload :quicklisp-slime-helper) or the one from melpa (e.g. bundled in spacemacs), and don't mix the two
17:25:51
_death
madrik: melpa is ok for emacs packages (although personally I hacked things so that I can easily diff changes and roll back if needed) but when it comes to CL, quicklisp or DIY package management is the way
17:26:29
hsaziz
I am being daft! I am typing this on Ubuntu 1910 and therefore had this in mind. I am actually having this issue on an ancient machine running Trisquel 8, which is also Ubuntu based. I think 16.04.
17:27:57
madrik
_death: I am aware that most languages today opt for and encourage the use of their own package management systems. But then, why do the maintainers of distributions spend so much time and effort integrating things?
17:29:02
_death
madrik: you'll have to ask them why.. maybe they just think "I'm a dist maintainer, I need to do my job"
17:30:02
_death
madrik: whereas a language user cares more about his particular niche working without pain
17:34:39
_death
madrik: maybe the difference is between "users" and "developers".. a dist maintainer sees "users" and tune to their perceived interests, while a "developers" are a fickle bunch that don't really form a homogeneous group of users, each subgroup can have different forces shaping its interests and values
17:35:27
madrik
I tend toward the distribution's view because when I obtain my software from my (distribution) vendor, I almost always get a managed, stress-free, well-put-together environment. The upgrades and security updates are taken care of, and the different components are made to work with each other.
17:36:44
amerlyq
madrik: maintainer thing is all about "fit all things together in global namespace" -- to actually reduce complexity and unavoidable context fragmentation
17:36:56
madrik
The objection to the distribution's view is that old software may have unfixed bugs dealt with in the newer versions.
17:37:28
_death
madrik: sure, I update some software via distribution, but when it comes to CL my method of "updating" is a git-fetch-all script and skimming new commits, putting more scrutiny into libraries I actually care about
17:39:24
madrik
In managing things yourself, you get control, but you also must exercise more responsibility. Whereas you can delegate a sizeable chunk of administration to the distribution on the other view.
17:39:26
amerlyq
I think the main point is splitting steps of "I'm ready to update all my software and deps" .vs. "I'm ready to do dev work". It's easy with distributors soft, but somewhat tiresome and opaque with quicklisp
17:40:39
madrik
amerlyq: Just to tee off, notice that the split in Python -- 2 v 3 -- was already painful. And then they have two different versions of each piece software.
17:42:19
jackdaniel
as name indicates, that are two differen languages -- that does tell how instable is the ecosystem ;)
17:42:22
amerlyq
it's only the question of pushing the responsibility to update all old soft, which will break on update. Either way somebody must do it
17:45:30
amerlyq
When you developing one project and use dynamic package manager -- you are somewhat ~ready~ to fix everything which breaks on each update in any deps API. When you periodically develop many projects... you are not so ~ready~, and do it rarely, after gathering great willpower.
17:45:42
_death
as a developer you are responsible for your dependencies and working environment.. there are conflicts that are resolved by taking more responsibility away from the distro
17:46:03
madrik
In connection with the discussion about SETQ v SETF the other day, I noted that symbol macros were mentioned. Where would they be used? What problem do they solve?
17:47:20
_death
madrik: I believe originally they were introduced to make WITH-SLOTS (and WITH-ACCESSORS, I guess) possible
17:47:41
hsaziz
makrk: THANK YOU!!! That worked! I actually wasted 2 1/2 hours yesterday wrestling with this.
17:48:19
madrik
_death: The main argument I read is that now each developer has to keep in step with security updates. This may seem undesirable, globally taken.
17:49:03
madrik
hsaziz: Glad to help. Just to cement this, read about removing and purging in apt/apt-get/aptitude/.
17:49:33
_death
madrik: either way you have to keep up with those.. you are responsible for your dependencies.. bad programmers think that by using a third party's update mechanism they are no longer responsible