I do mean Common Lisp. I think that it'd be preferable for Guix to use it because Lisp is more production-ready than Scheme: it standardises things that Scheme — even R7R2 large — doesn't; it's a pragmatic production language into which a lot of experience went. And of course there's CLOS, which is absolutely awesome. Even better, a well-written Guix-Lisp would be portable between multiple Common Lisp implementations; it's extraordinarily difficult to write a real system in Scheme, precisely because Scheme is so under-specified: really, Guix isn't written in Scheme; it's written in Guile Scheme.
Scheme is neat, and pretty, and very elegant, but it's not (even in its largest, most recent version) really meant for serious use on large systems. And I don't agree that it's a Lisp: it has only a single namespace, it breaks (car nil) → nil and (if nil "true" "false") → "false".
I'm aware that rms dislikes Lisp and wants Scheme to be GNU's extension language; IMHO he's wrong, and his attitude has really held back GNU, Emacs and the Lisp world at large. Had it not been for that attitude, we might have a Common Lisp Emacs by now, we might have a Common Lisp GNU userland by now, we might have a GNU which really is Not Unix, instead of a mess of C, security bugs & hacks.
Note that MacCarthy's Lisp didn't have (car nil); it was an error. I'm reluctant to insist that a language in the Lisp family must have (car nil), since that means that Lisp 1 and Lisp 1.5 aren't Lisp!
See this text in Steele and Gabriel's The Evolution of Lisp:
In
the
end
only
a
trivial
exchange
of
features
resulted
from
"the
great
MacLisp/Interlisp
summit":
MacLisp
adopted
from
Interlisp
the
behavior
(CAR NIL)
->
NIL
and
(CDR NIL)
->
NIL,
and
Interlisp
adopted
the
concept
of
a
read
table.
However, whether or not (car nil) works, it should express "the first element of the empty list, which is also false", rather than "the first element of a symbol that isn't related to lists and isn't Boolean false".
It's a tedious fruitless argument that goes back years. Some people in the "Common Lisp camp" believe that Common Lisp has the "rights" to the 'Lisp' "trademark."
As someone who programs in Clojure--and therefore has no justification for weighing in--I _believe_ that it's a cultural or generational difference. That is, for certain programmers (working in the 1980s? 1990s?) "Lisp" (capital-L, lower-case isp) meant Common Lisp, and many agreed.
I am sure that people tediously, fruitlessly argue about it. But it's also true that for a wide swath of programmers, Lisp is Common Lisp.
I wonder if hn's lisper or lispm could weigh in...
For a wide swath of programmers, a Lisp is something with lists made of mutable cons cells, terminated by a nil symbol which is both false and the empty list. I don't think you will encounter too many Common Lisp programmers who don't think that Emacs Lisp is a "Lisp".
Scheme doesn't use "Lisp" in its name. It has its own Usenet newsgroup; Scheme programming is rarely discussed in comp.lang.lisp. Likewise it has its own subreddit; r/lisp isn't used much for discussing Scheme.
"I would rather this were implemented in Scheme rather than Lisp" (or vice versa) is a perfectly understandable statement and sentiment that is not simply about semantic labels.
That's nice, but in Scheme, all pairs constructed by any code anywhere are mutable, and structure made out of mutable pairs can be passed into any library function. An object notation like (a b c) read from a stream gives you a mutable object.
It's a significant language difference that can't be papered over with a data type and handful of functions.
Racket supports both immutable and mutable cons cells.
Convenient or not - you decide.
Oh, been watching too much YouTube.
In both Racket and Scheme it is usually a good idea to program in a functional style - i.e. not to mutate pairs.
The compiler and runtime system can in some situations handle immutable pairs more efficiently than mutable pairs. So if mutable pairs are seldomly used, it makes sense to make immutable pairs the default.
The rationale why Racket made the shift is described here:
Arguments about labels are always tedious and fruitless. They don't advance anybody's understanding of anything important, like the substance of the whatever those labels might apply to. Arguing about whether or not "Lisp" means "Common Lisp" doesn't advance anybody's understanding of Common Lisp.
No, but the terminology of the root was plainly coming from the camp of "Scheme isn't Lisp, Common Lisp is Lisp." The child comment was confused by that peculiar terminology, so I provided context for that terminology in a way that I hoped would head off yet another argument about labels. It was my intent to stop the argument before it began.
The terminology is troublesome because "Scheme" more specifically determines the language than "Lisp", so "I'd prefer to use Lisp over Scheme" or vice versa is somewhat "apples versus vegetables".
> Arguing about whether or not "Lisp" means "Common Lisp" doesn't advance anybody's understanding of Common Lisp.
But not expecting Common Lisp to behave like Scheme helps. The design for the Scheme language is simply different from Common Lisp and thus code looks and behaves differently.
I agree with everything you said. The argument is tedious and fruitless. My point is an empirical one: Programmers of a Certain Age were more likely to use "Lisp" than programmers of other ages.
In my experience they often prefer that scheme/etc ceased to exist at all. I've had conversations with CL fanatics who accuse Scheme/etc of diluting Lisp by merely existing, and thereby harming CL.
Others aren't so extreme and just want people to stop saying "scheme is type of lisp."
I don't mind that Scheme exists, but I do mind that enthusiasts naively use it to build production systems, because they end up wasting time & energy re-implementing things the Common Lisp standard already specifies rather than spending that time & energy on the problems that they're actually trying to solve.
Scheme is another Blub: a Scheme user looks at Common Lisp and thinks, 'hey, I don't need generic functions; I don't need packages; I don't want separate namespaces for separate things; I don't want to extend my reader.' Meanwhile someone who's built large systems in both Lisp & Scheme realises how glad he is to have those things.
Meanwhile, the ecosystems of non-Lisp-family languages grow ever-larger, and hence ever-more-appealing, which is a problem because while Scheme-the-language is better than Python-the-language or Go-the-language, Scheme-the-fractured-ecosystem is worse than Python-the-healthy-ecosystem or Go-the-astoundingly-robust-ecosystem, which means more people use Python & Go, which means fewer people use Lisp-family languages … it's a vicious cycle.
Which means the world is a worse place, stuck in a local maximum of C-family languages and unable to break out to the Lispy global maximum.
> Scheme is another Blub: a Scheme user looks at Common Lisp and thinks, 'hey, I don't need generic functions; I don't need packages; I don't want separate namespaces for separate things; I don't want to extend my reader.' Meanwhile someone who's built large systems in both Lisp & Scheme realises how glad he is to have those things.
I find this list a little funny, because we do have generic functions, packages, and the ability to extend the reader. In Guix we use reader extensions for G-expressions, for example.
I grant you the separate namespaces thing, because, well, we really don't want to have a separate namespace for variables and procedures :)
> I find this list a little funny, because we do have generic functions, packages, and the ability to extend the reader.
But those are all non-standard, right? At least, I quickly skimmed through R7RS & don't see them in there. So they're either Guile-specific extensions, or your project implemented them, or they are a third-party library which has not undergone the same scrutiny as the standard itself.
FWIW, I find that having many namespaces (not just two!) rather than one is conducive to good program design.
