Discussion:
Common Lisp 3 proposal
(too old to reply)
Blake McBride
2020-09-21 22:08:18 UTC
Permalink
Greetings,

Common Lisp is getting old. Technology marches on. I think a
significant upgrade to CLtl2 is in order. Here are some ideas I have:

Leave Common Lisp as it is except:

1. Functions and variables share the same namespace

2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.

3. Change to a mixed-case language. The base language is lower-case.

4. Support real / native threads

5. Properly handle tail recursion

6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension.


These are just a few ideas. I think others can come up with more.

Although some of Common Lisp's functions are ugly with awkward
parameters, I think they're good enough for the most part and should be
left as-is so as not to change the language anymore than is necessary.

Blake McBride
Paul Rubin
2020-09-22 01:11:26 UTC
Permalink
Post by Blake McBride
1. Functions and variables share the same namespace
You're going to break all the CL code in the world by making CL a
Lisp-1. At that point you're making a new Lisp dialect with some CL
inspiration. There are still good things to say about CL, but why do
you want to ignore 40 years of newer developments? If you want a new
dialect, it's fine to make a deeper break with CL.

Based on the concurrency stuff you also mentioned, maybe you want
Lisp-Flavoured Erlang (LFE): https://lfe.io

Or maybe some mixture of LFE and Clojure, or maybe even just Clojure.
Blake McBride
2020-09-22 01:56:29 UTC
Permalink
Post by Paul Rubin
Post by Blake McBride
1. Functions and variables share the same namespace
You're going to break all the CL code in the world by making CL a
Lisp-1. At that point you're making a new Lisp dialect with some CL
inspiration. There are still good things to say about CL, but why do
you want to ignore 40 years of newer developments? If you want a new
dialect, it's fine to make a deeper break with CL.
First, CL broke with MacLisp and InterLisp and we, arguably, survived.

Second, comparatively speaking, CL is not used very much, and it's
likely decreasing. The changes I suggest would make Lisp much more
appealing to the newcomers. Making it Lisp-1 will make it much cleaner.
It's worth the effort to fix this once and for all.

Third, keeping with CLtl2 at much as possible and calling it CLtl3 does
a number of things:

a. Except for the changes I mentioned (plus other reasonable suggestions
from others), the system would be maximally familiar to current CL users.

b. Converting an existing CLtl2 implementation to CLtl3 would be easier.

c. Moving from CLtl2 to CLtl3 as opposed to creating yet another
dialect makes CLtl3 a bit more official.
Post by Paul Rubin
Based on the concurrency stuff you also mentioned, maybe you want
Lisp-Flavoured Erlang (LFE): https://lfe.io
LFE is Lisp-2.
Post by Paul Rubin
Or maybe some mixture of LFE and Clojure, or maybe even just Clojure.
Paul Rubin
2020-09-22 02:42:37 UTC
Permalink
Post by Blake McBride
First, CL broke with MacLisp and InterLisp and we, arguably, survived.
Some effort was made to maintain compatibility (no breakage nearly as
pervasive as going Lisp-1), there wasn't as much code around, there was
funding to do ports, etc.
Post by Blake McBride
Second, comparatively speaking, CL is not used very much, and it's
likely decreasing. The changes I suggest would make Lisp much more
appealing to the newcomers. Making it Lisp-1 will make it much
cleaner. It's worth the effort to fix this once and for all.
Lisp-2 has its advantages and supporters. I think at least some Lispers
chose CL over Scheme descendants specifically because they wanted Lisp-2.
Post by Blake McBride
c. Moving from CLtl2 to CLtl3 as opposed to creating yet another
dialect makes CLtl3 a bit more official.
Python 3 is much closer to Python 2 than your CL proposal and yet the
changeover was imho a debacle, taking 10+ years and still causing
problems and dissatisfaction.

People who want CL, it seems to me, want the CL that they have now and
not a newly broken one. People just getting started in Lisp probably
should not start with CL, but start with Scheme, try other dialects
including CL, and if they end up settling on CL then fine. And why
would they settle on CL instead of something else? It might be that
they find that they prefer Lisp-2.
Post by Blake McBride
LFE is Lisp-2.
Oh I didn't realize that. Of course you could make a Lisp-1 along the
same lines. I myself don't feel strongly about the issue. I do have
some stronger feelings about lexical scope (good), the loop macro (bad),
mandatory TRO (good, but most implementations have it even though it's
optional), etc.

Mostly though, I think that while Lisp itself still has areas of
applicability, and it's conceptually important for every language geek
to try out, "Big Lisp" is not really viable any more. Particularly, the
idea that CL can host an embedding of every significant PL feature out
there hasn't held up at all. Even if you add coroutines or threads,
there's still big areas like type systems that people want to use.
Blake McBride
2020-09-22 02:58:08 UTC
Permalink
Post by Paul Rubin
Post by Blake McBride
First, CL broke with MacLisp and InterLisp and we, arguably, survived.
Some effort was made to maintain compatibility (no breakage nearly as
pervasive as going Lisp-1), there wasn't as much code around, there was
funding to do ports, etc.
Post by Blake McBride
Second, comparatively speaking, CL is not used very much, and it's
likely decreasing. The changes I suggest would make Lisp much more
appealing to the newcomers. Making it Lisp-1 will make it much
cleaner. It's worth the effort to fix this once and for all.
Lisp-2 has its advantages and supporters. I think at least some Lispers
chose CL over Scheme descendants specifically because they wanted Lisp-2.
Post by Blake McBride
c. Moving from CLtl2 to CLtl3 as opposed to creating yet another
dialect makes CLtl3 a bit more official.
Python 3 is much closer to Python 2 than your CL proposal and yet the
changeover was imho a debacle, taking 10+ years and still causing
problems and dissatisfaction.
People who want CL, it seems to me, want the CL that they have now and
not a newly broken one. People just getting started in Lisp probably
should not start with CL, but start with Scheme, try other dialects
including CL, and if they end up settling on CL then fine. And why
would they settle on CL instead of something else? It might be that
they find that they prefer Lisp-2.
Post by Blake McBride
LFE is Lisp-2.
Oh I didn't realize that. Of course you could make a Lisp-1 along the
same lines. I myself don't feel strongly about the issue. I do have
some stronger feelings about lexical scope (good), the loop macro (bad),
mandatory TRO (good, but most implementations have it even though it's
optional), etc.
Mostly though, I think that while Lisp itself still has areas of
applicability, and it's conceptually important for every language geek
to try out, "Big Lisp" is not really viable any more. Particularly, the
idea that CL can host an embedding of every significant PL feature out
there hasn't held up at all. Even if you add coroutines or threads,
there's still big areas like type systems that people want to use.
From the sound of it (so many differing and unyielding opinions), I
suppose that ANSI CL is the end of the road for mainstream Lisp. Sure
there will be one-offs till the end of time but no "one main" Lisp
anymore beyond ANSI CL. I would create an implementation myself if I
had the time.

--blake
Paul Rubin
2020-09-22 03:49:20 UTC
Permalink
Post by Blake McBride
From the sound of it (so many differing and unyielding opinions), I
suppose that ANSI CL is the end of the road for mainstream Lisp.
Mainstream Lisp may already be history. Or maybe CL is still,
mainstream but could be succeeded by some revision that is still a
Lisp-2. Or maybe CL as mainstream Lisp could be succeeded by some other
dialect, perhaps Clojure. But I think that a Lisp-1 revision of CL is
dead in the water.

Elijah Stone - I've used various efforts to add optional typing to Lisp
and other languages but none so far have been that great. Type systems
are far more useful if they are sound, i.e. mandatory except for perhaps
very carefully marked escape holes (like unsafePerformIO). Optional
typing in Lisp is something like garbage collection in the presence of
C-style pointers. Yeah it can be sort of useful even then, but it's
much better if the language is designed around it.
Elijah Stone
2020-09-22 03:23:04 UTC
Permalink
I think that [...] "Big Lisp" is not really viable any more.
Particularly, the idea that CL can host an embedding of every
significant PL feature out there hasn't held up at all. Even if you add
coroutines or threads, there's still big areas like type systems that
people want to use.
You can get those too, see https://github.com/stylewarning/coalton for an
example.

The problem is that people don't want features. They want _cohesion_.
And that is much harder to provide. (See, for instance, _The Lisp Curse_,
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html). Not
impossible, of course, but not nearly so easy as with other contemporary
languages.
--
time flies like an arrow;
fruit flies like a banana
Zyni Moë
2020-09-22 09:34:32 UTC
Permalink
Post by Paul Rubin
Python 3 is much closer to Python 2 than your CL proposal and yet the
changeover was imho a debacle, taking 10+ years and still causing
problems and dissatisfaction.
Yes, Python 2 to Python 3 was huge saga because of gratuitous but small
changes.
Post by Paul Rubin
People who want CL, it seems to me, want the CL that they have now and
not a newly broken one. People just getting started in Lisp probably
should not start with CL, but start with Scheme, try other dialects
including CL, and if they end up settling on CL then fine. And why
would they settle on CL instead of something else? It might be that
they find that they prefer Lisp-2.
If you want a big Lisp-1, Racket is there.
--
the small snake
George Neuner
2020-09-22 13:55:14 UTC
Permalink
On Tue, 22 Sep 2020 09:34:32 -0000 (UTC), Zyni Moë
Post by Zyni Moë
Post by Paul Rubin
Python 3 is much closer to Python 2 than your CL proposal and yet the
changeover was imho a debacle, taking 10+ years and still causing
problems and dissatisfaction.
Yes, Python 2 to Python 3 was huge saga because of gratuitous but small
changes.
Post by Paul Rubin
People who want CL, it seems to me, want the CL that they have now and
not a newly broken one. People just getting started in Lisp probably
should not start with CL, but start with Scheme, try other dialects
including CL, and if they end up settling on CL then fine. And why
would they settle on CL instead of something else? It might be that
they find that they prefer Lisp-2.
If you want a big Lisp-1, Racket is there.
But Racket seems bent on becoming a statically typed language in the
near term, and in the long term abandoning SEXPR syntax.

The math array and matrix libraries already all but force you into the
typed language, because their performance in regular Racket is
horrible. The typed language is (documented) more than 20 *times*
faster performing operations in these libraries.

YMMV,
George
Zyni Moë
2020-09-22 14:52:13 UTC
Permalink
Post by George Neuner
But Racket seems bent on becoming a statically typed language in the
near term, and in the long term abandoning SEXPR syntax.
True: Racket is may be going to commit slow suicide because they did not
learn from Dylan (if Racket becomes infix, well, Python is just over here).
No reason for CL to also throw itself onto funeral pyre by making huge
mass of incompatible changes because someone who has lost track of how
alive CL is thinks it is dying and has bee in hair about case.
Post by George Neuner
The math array and matrix libraries already all but force you into the
typed language, because their performance in regular Racket is
horrible. The typed language is (documented) more than 20 *times*
faster performing operations in these libraries.
Is true I think. But you want fast portable (portably fast) numerical code
from CL? Good luck!

Am not suggesting Racket is better than CL: is single-implementation
language at mercy of people who did not learn lesson of Dylan.
--
the small snake
George Neuner
2020-09-22 17:25:40 UTC
Permalink
On Tue, 22 Sep 2020 14:52:13 -0000 (UTC), Zyni Moë
Post by Zyni Moë
Post by George Neuner
But Racket seems bent on becoming a statically typed language in the
near term, and in the long term abandoning SEXPR syntax.
True: Racket is may be going to commit slow suicide because they did not
learn from Dylan (if Racket becomes infix, well, Python is just over here).
No reason for CL to also throw itself onto funeral pyre by making huge
mass of incompatible changes because someone who has lost track of how
alive CL is thinks it is dying and has bee in hair about case.
Post by George Neuner
The math array and matrix libraries already all but force you into the
typed language, because their performance in regular Racket is
horrible. The typed language is (documented) more than 20 *times*
faster performing operations in these libraries.
Is true I think. But you want fast portable (portably fast) numerical code
from CL? Good luck!
Am not suggesting Racket is better than CL: is single-implementation
language at mercy of people who did not learn lesson of Dylan.
YMMV, but in my opinion Dylan's mistake was not static typing (which
was completely optional in the SEXPR version), but rather I think its
major mistake was going infix.

I actually am a fan of the (original) Dylan approach - which is
similar to the CL approach: write your program untyped and then tweak
performance with additional type annotation.


In any event, Racket appears to be following ML rather than Dylan. The
typed language relies heavily on type inference, but conventional
Racket/Scheme code is problematic for HM inference ... any non-trivial
program needs significant type annotation to compile. The developers
have stated the goal of improving inference (hopefully) to where it
can compile conventional untyped Racket/Scheme with minimal programmer
intervention.


George
Paul Rubin
2020-09-22 21:32:34 UTC
Permalink
Post by George Neuner
In any event, Racket appears to be following ML rather than Dylan.
I didn't realize Racket was going both typed and infix. If they want ML
why not just use ML, or Haskell or whatever? Lately I've gotten
interested in Purescript (purescript.org) which is a strict-evaluation
language with Haskell-ish types and syntax, that compiles fairly
naturally to Javascript and other languages. My main complaint about it
is that its toolchain smells too much of Javascript. E.g., it uses npm.
Azathoth Hastur
2020-10-11 21:20:53 UTC
Permalink
Post by Paul Rubin
Post by George Neuner
In any event, Racket appears to be following ML rather than Dylan.
I didn't realize Racket was going both typed and infix. If they want ML
why not just use ML, or Haskell or whatever? Lately I've gotten
interested in Purescript (purescript.org) which is a strict-evaluation
language with Haskell-ish types and syntax, that compiles fairly
naturally to Javascript and other languages. My main complaint about it
is that its toolchain smells too much of Javascript. E.g., it uses npm.
exactly!
Zyni Moë
2020-09-24 15:39:50 UTC
Permalink
Post by George Neuner
YMMV, but in my opinion Dylan's mistake was not static typing (which
was completely optional in the SEXPR version), but rather I think its
major mistake was going infix.
Yes agree, that is what I meant sorry was not clear enough. Lisp's big win
is not being infix: low-commitment syntax. An infix Lisp isn't. Did not
even remember/know Dylan had static typing.

Moving to infix because sexp frightens people is like working in components
in GR because tensor algebra frightens people. Does frighten people but
try to do GR without is fucking insane. And I want language for doing GR
please. (By the way first exposure to Lisp was ... doing GR.j
--
the small snake
Paul Rubin
2020-09-24 17:10:50 UTC
Permalink
Post by Zyni Moë
Yes agree, that is what I meant sorry was not clear enough. Lisp's big win
is not being infix: low-commitment syntax. An infix Lisp isn't. Did not
even remember/know Dylan had static typing.
I wasn't around for Dylan but sexpr syntax is something of an
implementation artifact: sexprs were historically intended to eventually
be supplanted by infix "mexprs" but mexprs never caught on. It still
almost seems like a bikeshed issue from a contemporary perspective.
Lisp's big win was that it turned Church's lambda calculus into a
programming language, though clumsily at first. These days Scheme comes
closer, and there are also infix languages (Haskell, ML) that are also
essentially implementations of lambda calculus as programming.

Anyway, this goes pretty far back:

https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf
Stefan Monnier
2020-09-24 17:51:11 UTC
Permalink
Post by Paul Rubin
Post by Zyni Moë
Yes agree, that is what I meant sorry was not clear enough. Lisp's big win
is not being infix: low-commitment syntax. An infix Lisp isn't. Did not
even remember/know Dylan had static typing.
I wasn't around for Dylan but sexpr syntax is something of an
implementation artifact: sexprs were historically intended to eventually
be supplanted by infix "mexprs" but mexprs never caught on. It still
almost seems like a bikeshed issue from a contemporary perspective.
Lisp's big win was that it turned Church's lambda calculus into a
programming language, though clumsily at first. These days Scheme comes
closer, and there are also infix languages (Haskell, ML) that are also
essentially implementations of lambda calculus as programming.
Yes, one major contribution of Lisp is functional programming, but the
powerful macro system is another major one, that got lost along the way
to Haskell/ML's infix syntax.

In my toy language Typer I try to correct this error by using an infix
syntax that's more restrictive/regular (a bit like Prolog) so as to
preserve more of Lisp's syntactic procedural macros.


Stefan
Paul Rubin
2020-09-24 21:28:57 UTC
Permalink
Post by Stefan Monnier
Yes, one major contribution of Lisp is functional programming, but the
powerful macro system is another major one, that got lost along the way
to Haskell/ML's infix syntax.
Lisp comes to us from the dawn of programming and I think programmable
surface syntax was a "phase" of language design in the 1970s-80s. Being
able to create a new custom language for every application must have
seemed exciting at the time. Forth did it too, and Forthers also
thought it was important. Later, programs got too big and long-lived
for people to want to deal with yet another cognitive burden if they
could help it, and at the same time, programming practice converged more
and the space of useful syntax features became better understood.

If Lisp's sexp syntax taught us anything, it's that surface syntax is
not that important an aspect of a PL. But maybe ironically, by that
same reasoning, sexp syntax itself is not that important a feature of
Lisp.

There are occasions when you want to embed a DSL or use metaprogramming
in an application and it's good to have some kind of hook for that, but
sexps are just one possible approach. Lazy evaluation (like in Haskell)
handles the usual case where a macro is just a function that takes
unevaluated args as black boxes (think of implementing IF in terms of
COND). I still like Lisp, though I haven't used it much recently. I
don't dislike sexp syntax but I don't really miss it that much.
However, of course, that's just me.
Post by Stefan Monnier
In my toy language Typer I try to correct this error by using an infix
syntax that's more restrictive/regular (a bit like Prolog) so as to
preserve more of Lisp's syntactic procedural macros.
This sounds nice but are hygienic macros more expected now? I don't
really follow this stuff any more.

Haskell currently has a horrid metaprogramming system (Quasiquote).
There have also been a couple of Lispish syntaxes proposed for Haskell,
along the lines of LFE. It might be nice to standardize one of them,
and have Quasiquote operate on it instead of the ugly Haskell AST's that
it currently uses.

I've been wanting to figure out how MetaOCaml works. Unlike GHC
Quasiquote and unlike Lisp macros, I believe MetaOCaml is typed, which
makes sense for an ML-like language. That means that a macro can't
create a syntactically invalid substitution fragment. Quasiquote can
paste any weird cruft into your program and then it's up to the usual
compiler front end to spot syntax errors. That makes the error messages
nearly unusable, like you might have seen with C++ template errors.
Stefan Monnier
2020-09-24 21:54:24 UTC
Permalink
Post by Paul Rubin
There are occasions when you want to embed a DSL or use metaprogramming
in an application and it's good to have some kind of hook for that, but
sexps are just one possible approach.
Yes, the programmable syntax in Typer is meant for:
- provide a "ML-like surface syntax" while still being amenable to
Lisp-style macros (instead of Template-Haskell).
- Make it possible to design new syntaxes for DSLs.
The system also allows programmers to write completely opaque code by
redefining precedences all over the place, but I don't worry about that.

Note that this kind of extensible syntax is fairly popular in proof
assistants like Coq and Agda where you often want to try and mimic some
established notation from math.
Post by Paul Rubin
Haskell currently has a horrid metaprogramming system (Quasiquote).
There have also been a couple of Lispish syntaxes proposed for Haskell,
along the lines of LFE. It might be nice to standardize one of them,
and have Quasiquote operate on it instead of the ugly Haskell AST's that
it currently uses.
I find Lisp-style parenthesized notation too heavyweight for statically
typed languages.
Post by Paul Rubin
I've been wanting to figure out how MetaOCaml works. Unlike GHC
Quasiquote and unlike Lisp macros, I believe MetaOCaml is typed, which
makes sense for an ML-like language.
MetaOCaml can't be used for syntactic extensions. It's for runtime
code generation, also called "staged computation". It's related to
macro-style metaprogramming yet is quite different.


Stefan
Paul Rubin
2020-09-24 22:13:00 UTC
Permalink
Post by Stefan Monnier
Note that this kind of extensible syntax is fairly popular in proof
assistants like Coq and Agda where you often want to try and mimic some
established notation from math.
Hmm, I didn't know Coq or Agda had that. I know that Agda has mixfix
expressions that can implement things like C's "a ? b : c" syntax. I
might take another look. Yet another thing I've been wanting to
understand.
Post by Stefan Monnier
I find Lisp-style parenthesized notation too heavyweight for statically
typed languages.
Yes, the idea is you wouldn't directly program in Lisp-like syntax, but
the macro syntax could get sexps instead of complicated AST's. Or else
the AST's could use GHC typing extensions (GADT's I guess), which I
don't think they currently do.

I don't remember how the extensions work but iirc, Template Haskell (TH)
was relatively sane but somewhat restricted. Quasiquote (QQ) can do
arbitrary transformations (similar to Lisp macros) but using it looked
horribly messy.
Post by Stefan Monnier
MetaOCaml can't be used for syntactic extensions. It's for runtime
code generation, also called "staged computation".
Oh I see, that makes sense. Thanks. In Haskell, I wonder if you could
just create an "optimize" function that you give an arbitrary function
value to, that then runs all the GHC compilation machinery and gives
back another function that does the same thing, as optimized machine
code. Then there wouldn't have to be a special metaprogramming feature.
You could just tell the compiler to keep more first-stage metadata
around for the function values while they were being built, to assist
the compiler in optimizing at the second stage.
Stefan Monnier
2020-09-24 22:56:56 UTC
Permalink
Post by Paul Rubin
Post by Stefan Monnier
I find Lisp-style parenthesized notation too heavyweight for statically
typed languages.
Yes, the idea is you wouldn't directly program in Lisp-like syntax, but
the macro syntax could get sexps instead of complicated AST's.
Yes, that's what I do in Typer (and more or less applies to Prolog as
well). E.g. the infix syntax

let x = 1 in e

is equivalent to

let_in_ (_=_ x 1) e

in the sense that the reader returns the same sexps for both, i.e. just
like (1 2) is equivalent to (1 . (2 . ())) in Lisp.

It's mostly the same as Agda's mixfix (except that I use it for the
whole language).


Stefan
George Neuner
2020-09-25 02:52:55 UTC
Permalink
On Thu, 24 Sep 2020 14:28:57 -0700, Paul Rubin
Post by Paul Rubin
Lisp comes to us from the dawn of programming and I think programmable
surface syntax was a "phase" of language design in the 1970s-80s. Being
able to create a new custom language for every application must have
seemed exciting at the time. Forth did it too, and Forthers also
thought it was important. Later, programs got too big and long-lived
for people to want to deal with yet another cognitive burden if they
could help it, and at the same time, programming practice converged more
and the space of useful syntax features became better understood.
If Lisp's sexp syntax taught us anything, it's that surface syntax is
not that important an aspect of a PL. But maybe ironically, by that
same reasoning, sexp syntax itself is not that important a feature of
Lisp.
Lisp's SEXPR syntax was a nearly ideal compile target - being
essentially just a (decorated) AST.
Post by Paul Rubin
There are occasions when you want to embed a DSL or use metaprogramming
in an application and it's good to have some kind of hook for that, but
sexps are just one possible approach. Lazy evaluation (like in Haskell)
handles the usual case where a macro is just a function that takes
unevaluated args as black boxes (think of implementing IF in terms of
COND). I still like Lisp, though I haven't used it much recently. I
don't dislike sexp syntax but I don't really miss it that much.
However, of course, that's just me.
Racket has quite a few DSLs that integrate by compiling/transpiling
intothe common SEXPR language. Together with its modules, you can
write portions of your program in DSL languages that are closer to the
actual problem being addressed.

There are a dozen[1] "module languages" (DSLs) that ship with Racket
and more are available as user contributions. It's actually pretty
easy to create your own: basically you just need to parse your chosen
syntax, and emit Racket code that implements the semantics. Module
languages can get integration with ordinary Racket code and other
module languages essentially for free.

This is subtly different from macros: in Racket a module language is a
separate compilation unit. A module language can be designed like a
stand alone interpreter in which the "program" is simply transpiled
into Racket and immediately executed, or it can be designed so that it
emits code to be integrated / embedded into ordinary Racket programs.
If you are careful, it can be made to work either way.


[Of course, easy DSLs are likely to be a casuality of moving to infix
syntax. The Racket developers claim the SEXPR syntax will continue to
be supported - at least as a transpile target - but who knows.]


George

[1] https://docs.racket-lang.org/
Zyni Moë
2020-09-24 19:20:56 UTC
Permalink
Post by Paul Rubin
I wasn't around for Dylan but sexpr syntax is something of an
implementation artifact: sexprs were historically intended to eventually
be supplanted by infix "mexprs" but mexprs never caught on.
Yes I do know this quite well thank you. People did think they were trying
to implement already-existing lambda calculus, did not realise they were
really inventing not-already-existing macros. Just like Hammond thought
was trying to make cheap church organ, did not realise was making
instrument played by Booker T jones & Jon Lord. Other people did lambda
calculus too: turns out macros and source-code-as-data were the interesting
thing about lisp. No infix language I know gets anywhere near power (not
formal power, formal power is easy) and elegance of lisp-family macros.
Infix means endless boring saga of worry about operator precedence, sexp
means not.
--
the small snake
Madhu
2020-09-25 12:08:41 UTC
Permalink
Point your newsreader to nntp.olduse.net subscribe to comp.lang.lisp and
you can see this same discussion on threads like "virtues of lisp
syntax" and variants. From 30 years, ago this week.

[others may have also been interested in another thread from 30 years and
24 weeks ago on "why lisp is dead" on license fees but that has expired
on that server]
none) (albert
2020-09-22 16:44:41 UTC
Permalink
Post by Zyni Moë
Post by Paul Rubin
Python 3 is much closer to Python 2 than your CL proposal and yet the
changeover was imho a debacle, taking 10+ years and still causing
problems and dissatisfaction.
Yes, Python 2 to Python 3 was huge saga because of gratuitous but small
changes.
gratuitous , yes. Small no.
I think it is a big deal that
(A<B<C)
neither means
((A<B)<C)
not
(A<(B<C))
Post by Zyni Moë
--
the small snake
Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Zyni Moë
2020-09-24 15:39:49 UTC
Permalink
Post by none) (albert
gratuitous , yes. Small no.
I think it is a big deal that
(A<B<C)
neither means
((A<B)<C)
not
(A<(B<C))
Is that change? Both 2.7 and 3.x docs say 'Formally, if a, b, c, …, y, z
are expressions and op1, op2, …, opN are comparison operators, then a op1 b
op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z,
except that each expression is evaluated at most once.'

This is interpretation maths person like me would want: 'a < b < c' should
mean 'b in (a, c)' not any other thing. But may be it changed from some
broken semantics: if did that is not a small change yes.
--
the small snake
Jeff Barnett
2020-09-24 16:54:55 UTC
Permalink
Post by Zyni Moë
Post by none) (albert
gratuitous , yes. Small no.
I think it is a big deal that
(A<B<C)
neither means
((A<B)<C)
not
(A<(B<C))
Is that change? Both 2.7 and 3.x docs say 'Formally, if a, b, c, …, y, z
are expressions and op1, op2, …, opN are comparison operators, then a op1 b
op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z,
except that each expression is evaluated at most once.'
This is interpretation maths person like me would want: 'a < b < c' should
mean 'b in (a, c)' not any other thing. But may be it changed from some
broken semantics: if did that is not a small change yes.
Are you all sure that you don't mean (< A B C) in CL? Where is (A<B<C) a
legal expression?
--
Jeff Barnett
Zyni Moë
2020-09-24 19:13:12 UTC
Permalink
Post by Jeff Barnett
Are you all sure that you don't mean (< A B C) in CL? Where is (A<B<C) a
legal expression?
Python (but obvs do not need parens except if want precedence control).
--
the small snake
Madhu
2020-09-22 06:08:24 UTC
Permalink
Post by Blake McBride
Post by Paul Rubin
Post by Blake McBride
1. Functions and variables share the same namespace
You're going to break all the CL code in the world by making CL a
Lisp-1. At that point you're making a new Lisp dialect with some CL
inspiration. There are still good things to say about CL, but why do
you want to ignore 40 years of newer developments? If you want a new
dialect, it's fine to make a deeper break with CL.
First, CL broke with MacLisp and InterLisp and we, arguably, survived.
Second, comparatively speaking, CL is not used very much, and it's
likely decreasing. The changes I suggest would make Lisp much more
appealing to the newcomers.
Honestly this concern for newcomers is like patriotism being the last
resort for some people.

your motivation derives from your personal hatred for Lisp-2

The last honest bit of language design ended with perl5. Witness the
endtimes capital of the antichrist being investing in programming
languages to destroy generations while a few children of the kindgom
profit from the HR turnaround exploiting humanity as it delivers the
souls to satan.

common lisp is a finished work. attacking it is futile.
Azathoth Hastur
2020-10-11 21:00:26 UTC
Permalink
Post by Madhu
Post by Blake McBride
Post by Paul Rubin
Post by Blake McBride
1. Functions and variables share the same namespace
You're going to break all the CL code in the world by making CL a
Lisp-1. At that point you're making a new Lisp dialect with some CL
inspiration. There are still good things to say about CL, but why do
you want to ignore 40 years of newer developments? If you want a new
dialect, it's fine to make a deeper break with CL.
First, CL broke with MacLisp and InterLisp and we, arguably, survived.
Second, comparatively speaking, CL is not used very much, and it's
likely decreasing. The changes I suggest would make Lisp much more
appealing to the newcomers.
Honestly this concern for newcomers is like patriotism being the last
resort for some people.
your motivation derives from your personal hatred for Lisp-2
The last honest bit of language design ended with perl5. Witness the
endtimes capital of the antichrist being investing in programming
languages to destroy generations while a few children of the kindgom
profit from the HR turnaround exploiting humanity as it delivers the
souls to satan.
common lisp is a finished work. attacking it is futile.
I wish more lisp web apps!!

Viaweb cleverly sidestepped teh concurrency problem by simpyl forking a cl interpreter for each web client!!
BRILIANT
Azathoth Hastur
2020-10-11 20:59:06 UTC
Permalink
Post by Blake McBride
Post by Paul Rubin
Post by Blake McBride
1. Functions and variables share the same namespace
You're going to break all the CL code in the world by making CL a
Lisp-1. At that point you're making a new Lisp dialect with some CL
inspiration. There are still good things to say about CL, but why do
you want to ignore 40 years of newer developments? If you want a new
dialect, it's fine to make a deeper break with CL.
First, CL broke with MacLisp and InterLisp and we, arguably, survived.
Second, comparatively speaking, CL is not used very much, and it's
likely decreasing. The changes I suggest would make Lisp much more
appealing to the newcomers. Making it Lisp-1 will make it much cleaner.
It's worth the effort to fix this once and for all.
Third, keeping with CLtl2 at much as possible and calling it CLtl3 does
a. Except for the changes I mentioned (plus other reasonable suggestions
from others), the system would be maximally familiar to current CL users.
b. Converting an existing CLtl2 implementation to CLtl3 would be easier.
c. Moving from CLtl2 to CLtl3 as opposed to creating yet another
dialect makes CLtl3 a bit more official.
Post by Paul Rubin
Based on the concurrency stuff you also mentioned, maybe you want
Lisp-Flavoured Erlang (LFE): https://lfe.io
LFE is Lisp-2.
Post by Paul Rubin
Or maybe some mixture of LFE and Clojure, or maybe even just Clojure.
ban oracle and microsoft
Elijah Stone
2020-09-22 01:20:19 UTC
Permalink
Post by Blake McBride
Common Lisp is getting old. Technology marches on. I think a
*snip*
I don't think any of these are /bad/ ideas, per se. In fact, I think most
of them are quite good ideas (the exception being shared namespaces--it's
certainly not an idea without merit, but bears further discussion).

However, I don't think any of these are worth breaking decades of shared
compatibility for. None of them except for the first is a particularly
big deal; none is particularly hard to work around in code. You need a
better value proposition.
Post by Blake McBride
3. Change to a mixed-case language. The base language is lower-case.
You can get this trivially with (setf (readtable-case *readtable*) :invert))
--
time flies like an arrow;
fruit flies like a banana
Blake McBride
2020-09-22 01:29:56 UTC
Permalink
Post by Elijah Stone
Post by Blake McBride
Common Lisp is getting old. Technology marches on. I think a
*snip*
I don't think any of these are /bad/ ideas, per se. In fact, I think most
of them are quite good ideas (the exception being shared namespaces--it's
certainly not an idea without merit, but bears further discussion).
However, I don't think any of these are worth breaking decades of shared
compatibility for. None of them except for the first is a particularly
big deal; none is particularly hard to work around in code. You need a
better value proposition.
Post by Blake McBride
3. Change to a mixed-case language. The base language is lower-case.
You can get this trivially with (setf (readtable-case *readtable*) :invert))
Not completely. I'm currently writing a Scheme to C# converter in
Common Lisp. Dealing with all the |MyFunction| is tedious. It would be
a lot easier of CL just allows mixed case.

Blake
Azathoth Hastur
2020-10-11 20:58:39 UTC
Permalink
Post by Blake McBride
Post by Elijah Stone
Post by Blake McBride
Common Lisp is getting old. Technology marches on. I think a
*snip*
I don't think any of these are /bad/ ideas, per se. In fact, I think most
of them are quite good ideas (the exception being shared namespaces--it's
certainly not an idea without merit, but bears further discussion).
However, I don't think any of these are worth breaking decades of shared
compatibility for. None of them except for the first is a particularly
big deal; none is particularly hard to work around in code. You need a
better value proposition.
Post by Blake McBride
3. Change to a mixed-case language. The base language is lower-case.
You can get this trivially with (setf (readtable-case *readtable*) :invert))
Not completely. I'm currently writing a Scheme to C# converter in
Common Lisp. Dealing with all the |MyFunction| is tedious. It would be
a lot easier of CL just allows mixed case.
Blake
ban microsoft and oracle

use common lisp

you might want picolisp
Zyni Moë
2020-09-22 09:25:13 UTC
Permalink
I think a significant upgrade to CLtl2 is in order.
CLtL2 was never standard for CL, certainly is not now.
1. Functions and variables share the same namespace
... and break huge number of existing programs. Is good start, yes. Also
please to rename all functions in Ukrainian: small change I think.
3. Change to a mixed-case language. The base language is lower-case.
Break some more programs and open way for horrid camels. can also replace
all hyphens in symbols by n-dash for amusement perhaps?
--
the small snake
Manfred Bergmann
2020-09-22 10:05:20 UTC
Permalink
Hi.

Since I'm just a new one-year user of CL I might not fully understand all the bits and pieces.
In my daily life I use all the shiny new languages, (Kotlin, Swift, Elixir, you name it).

Since I came to the CL world I did understand that none of this new shiny stuff give the benefit that most believe.
And hence CL development is so interactive like no other development environment.
When in agile development we're talking about a quick feedback loop, there is no quicker feedback loop as in CL.
In particular now that 'quicklisp' allows to load libraries directly into the image and use them in the REPL.
No other dev environment has that. At least I haven't seen it yet.
Post by Blake McBride
1. Functions and variables share the same namespace
I believe, as some pointed out this would effectively be Racket.
Post by Blake McBride
4. Support real / native threads
Isn't this what Bordeaux-Threads does?
Post by Blake McBride
5. Properly handle tail recursion
I might be wrong. But don't SBCL and CCL (at least) support tail recursion?
Post by Blake McBride
6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension

There is 'usocket', but I agree that in particular for async handling of this there could be some improvements.


For me as a new CL user I had in particular a hard time with the available documentation.
This is what really is old and this is what should have high priority.

The hyperspec is for geeks.

This: http://jtra.cz/stuff/lisp/sclr/index.html
Is not sufficient.

The rest (quickdoc, quickref) is close to useless.


Cheers,
Manfred
Post by Blake McBride
Greetings,
Common Lisp is getting old. Technology marches on. I think a
1. Functions and variables share the same namespace
2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.
3. Change to a mixed-case language. The base language is lower-case.
4. Support real / native threads
5. Properly handle tail recursion
6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension.
These are just a few ideas. I think others can come up with more.
Although some of Common Lisp's functions are ugly with awkward
parameters, I think they're good enough for the most part and should be
left as-is so as not to change the language anymore than is necessary.
Blake McBride
Zyni Moë
2020-09-22 10:13:36 UTC
Permalink
Post by Manfred Bergmann
I believe, as some pointed out this would effectively be Racket.
Would not be Racket, but Racket does all this, is also huge language.
Post by Manfred Bergmann
Post by Blake McBride
4. Support real / native threads
Isn't this what Bordeaux-Threads does?
Yes.
Post by Manfred Bergmann
Post by Blake McBride
5. Properly handle tail recursion
I might be wrong. But don't SBCL and CCL (at least) support tail recursion?
Yes: think all live implementations support tail call elimination. Is
another non-problem.

... And meanwhile no-one mentions huge elephant falling through ceiling:
standardise unicode and i18n. Because that is boring hard work especially
to subset of native English speakers. Fixing that would be a worthwhile
change.
--
the small snake
Manfred Bergmann
2020-09-22 10:40:07 UTC
Permalink
standardise unicode and i18n. Because that is boring hard work especially
to subset of native English speakers. Fixing that would be a worthwhile
change.
I think there would be many areas where improvement could highly increase the visibility of CL.
The language itself doesn't really need much attention, IMO.

IDEs:
Yes, I love Emacs. But many find it too geeky. This is a barrier.
There is effort going on to support other editors like Atom and VS Code.
But what about IntelliJ?

Webapps:
We've got it all, the libraries I mean, Hunchentoot, cl-who, spinneret, cl-i18n, parenscript, etc.
There could be a (ONE, not 5) kick-as web framework in CL which would draw attention.
Similar to Phoenix in Elixir.
none) (albert
2020-09-22 12:59:41 UTC
Permalink
Post by Blake McBride
Greetings,
Common Lisp is getting old. Technology marches on. I think a
1. Functions and variables share the same namespace
2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.
3. Change to a mixed-case language. The base language is lower-case.
I'm not familiar with the term mixed-case. Does it mean case-insensitive
or on the contrary case-sensitive? Or even something different yet?
Post by Blake McBride
4. Support real / native threads
5. Properly handle tail recursion
6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension.
These are just a few ideas. I think others can come up with more.
Although some of Common Lisp's functions are ugly with awkward
parameters, I think they're good enough for the most part and should be
left as-is so as not to change the language anymore than is necessary.
Blake McBride
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Paul Rubin
2020-09-22 21:39:00 UTC
Permalink
Post by none) (albert
I'm not familiar with the term mixed-case. Does it mean case-insensitive
or on the contrary case-sensitive? Or even something different yet?
Case-sensitive. In CL, foo, Foo, and FOO are all the same symbol.
Grumbling about this to CL fans back in the day would get the response
"Why should case make a difference? What about fonts while you're
at it? Should foo, boldface foo, italic foo, underlined foo, etc
all be different?". I don't know if anyone says this any more.

I never really used them but Lisp machine keyboards had something like 5
different shift keys (shift, control, meta, super, hyper) each of which
controlled a different bit in the character coding. So it really was
possible to use identifiers with different combinations of font modifiers.
none) (albert
2020-09-23 12:26:28 UTC
Permalink
Post by Paul Rubin
Post by none) (albert
I'm not familiar with the term mixed-case. Does it mean case-insensitive
or on the contrary case-sensitive? Or even something different yet?
Case-sensitive. In CL, foo, Foo, and FOO are all the same symbol.
Grumbling about this to CL fans back in the day would get the response
"Why should case make a difference? What about fonts while you're
at it? Should foo, boldface foo, italic foo, underlined foo, etc
all be different?". I don't know if anyone says this any more.
The growing influence of Chinese, and the waning of uppercase-only
typewriters. (Got a dec writer in the basement, will sell it for
what I paid for it, say 4000 euro.)
Uppercase in Chinese makes no sense, in case you didn't know.
Post by Paul Rubin
I never really used them but Lisp machine keyboards had something like 5
different shift keys (shift, control, meta, super, hyper) each of which
controlled a different bit in the character coding. So it really was
possible to use identifiers with different combinations of font modifiers.
Programs with comment in chinese are hard enough as it is. We don't
need having identifiers in different chinese fonts. That would be
marginably readable in high quality print. Nowadays high resolution
screens could be up to it, but my eyes aren't.

(I'm firmly in the camp of "exterminate all case-insensitive junk".)

Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Blake McBride
2020-09-22 13:59:18 UTC
Permalink
Okay. Clearly this is a non-starter.

How about baby steps. How about just #3? This should be relatively
easy, and it can be done by simply adding an option to readtable-case.

#4 is already happening in some implementations. (It is critical in
some instances because without it you're confined to a single processor.)

#5 and #6 are also partially done in many implementations. I just
thought standardizing this stuff may be helpful.

Blake
Post by Blake McBride
Greetings,
Common Lisp is getting old.  Technology marches on.  I think a
1. Functions and variables share the same namespace
2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.
3. Change to a mixed-case language.  The base language is lower-case.
4. Support real / native threads
5. Properly handle tail recursion
6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension.
These are just a few ideas.  I think others can come up with more.
Although some of Common Lisp's functions are ugly with awkward
parameters, I think they're good enough for the most part and should be
left as-is so as not to change the language anymore than is necessary.
Blake McBride
Blake McBride
2020-09-22 14:41:32 UTC
Permalink
Okay.  Clearly this is a non-starter.
How about baby steps.  How about just #3?  This should be relatively
easy, and it can be done by simply adding an option to readtable-case.
To be a bit clearer on what I mean here:

Create a new readtable-case mode called :preserve-lower.
What this does is preserve case, as it does now, but all existing
symbols get converted to lower-case.
#4 is already happening in some implementations.  (It is critical in
some instances because without it you're confined to a single processor.)
#5 and #6 are also partially done in many implementations.  I just
thought standardizing this stuff may be helpful.
Blake
Post by Blake McBride
Greetings,
Common Lisp is getting old.  Technology marches on.  I think a
1. Functions and variables share the same namespace
2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.
3. Change to a mixed-case language.  The base language is lower-case.
4. Support real / native threads
5. Properly handle tail recursion
6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension.
These are just a few ideas.  I think others can come up with more.
Although some of Common Lisp's functions are ugly with awkward
parameters, I think they're good enough for the most part and should
be left as-is so as not to change the language anymore than is necessary.
Blake McBride
Zyni Moë
2020-09-24 15:15:38 UTC
Permalink
Post by Blake McBride
Create a new readtable-case mode called :preserve-lower.
What this does is preserve case, as it does now, but all existing
symbols get converted to lower-case.
So now every time you bind or assign to *readtable* is possibly huge change
to whole system. (set x y) becomes full of terror. And what if there are
two distinct interned symbols whose names differ only in case? Some of us
had to worry about all this with allegro 'modern' mode: was fucking
compatibility nightmare.
--
the small snake
Blake McBride
2020-09-24 20:48:46 UTC
Permalink
Post by Zyni Moë
Post by Blake McBride
Create a new readtable-case mode called :preserve-lower.
What this does is preserve case, as it does now, but all existing
symbols get converted to lower-case.
So now every time you bind or assign to *readtable* is possibly huge change
to whole system. (set x y) becomes full of terror. And what if there are
two distinct interned symbols whose names differ only in case? Some of us
had to worry about all this with allegro 'modern' mode: was fucking
compatibility nightmare.
The new mode is not for old code. Changing any of the modes on
pre-existing code is likely to mess it up.

In JavaScript they have: 'use strict'
That changes the language in incompatible ways that can break old code.
All new code for years start with those lines to make the language more
strict (and easier to debug).

The point of the change to CL is not to use it on old code. New code
written where the programmer wants to use mixed-case but not in an
inverted fashion would use it.

In fact, I am currently writing a program to convert Scheme into C#.
I'm writing it in Common Lisp. The case stuff is an unnecessary pain in
the butt.

Blake McBride
Zyni Moë
2020-09-25 09:30:37 UTC
Permalink
Post by Blake McBride
The new mode is not for old code. Changing any of the modes on
pre-existing code is likely to mess it up.
Did you read what I wrote? Perhaps you read but obviously did not
understand. Is nothing to do with old code is to do with implementation.
If readtable controls case of symbol names then changing readtable may
require change in case of symbol names and thus implementation must check
for this every time readtable is changed. This means every call to SET,
every incantation of (SETF (SYMBOL-VALUE ...) ...) must now check for this
at least.

And implementation must, when readtable is changed to toxic one, now deal
with what happens if it has two symbols whose names differ only in case.
Because implementation must do the right thing because this is standard so
must be language-quality. But is completely unclear what the right thing
is at all in this case.

Much worse, we all want native threads (we have native threads so that is
good). So now can have two threads with different readtables and thus
*different cases for symbol names at the same time*. Only hope would be to
force symbols to have two name slots and SYMBOL-NAME would need to check
the current readtable to know which one to look up.

This is all fucked up, and it is fucked up because the readtable is machine
which tells reader which data to construct or find corresponding to input
stream. Is not a place to control what the names of existing symbols are
and using it for that is stupid.

Not using readtable but some other mechanism is better. But is still hard
if that new mechanism is dynamic at all: still probably need two name
slots, still have problems of mixed-case.

Also you keep going on about how it is inconvenient to deal with symbols
with mixed case (or lower case). Why don't you just solve that problem in
CL? Here is approach:

- write tiny function which takes package (CL for eg) and computes other
package with lowercase symbols, all symbols in new package have plist entry
pointing at their parents (or store mapping in table elsewhere does not
matter);
- write slightly less tiny function which walks over a form produces new
form with symbols with pointers to old symbols substituted;
- write wrappers for load / compile / compile-file / eval / repl which use
second function.

Now you have something you can use in lowercase. Hard bit is second
function: is easy to deal with most cases but array literals any other
object which might contain symbols in code need to be copied and this is
fiddly. But this is fine system does not need to be language-quality can
just not handle these cases and decide that you never do these things in
code you write.

First two of these took me ten mins with second fn explicitly not dealing
with complicated cases. Third part would be more fiddly (remember it only
has to work: does not need to be language-quality), mostly because would
need to understand enough of SLIME etc to make that work properly.

What you are doing sounds like standard displacement activity: 'I have
problem I need to solve which I could solve but I don't want to so I will
propose vast changes to language which I know will never happen so I have
excuse not to solve problem'. Used to be really common behaviour by people
on CLL, glad to see nothing has changed.
--
the small snake
Blake McBride
2020-09-26 15:24:08 UTC
Permalink
Post by Zyni Moë
Post by Blake McBride
The new mode is not for old code. Changing any of the modes on
pre-existing code is likely to mess it up.
Did you read what I wrote? Perhaps you read but obviously did not
understand. Is nothing to do with old code is to do with implementation.
If readtable controls case of symbol names then changing readtable may
require change in case of symbol names and thus implementation must check
for this every time readtable is changed. This means every call to SET,
every incantation of (SETF (SYMBOL-VALUE ...) ...) must now check for this
at least.
And implementation must, when readtable is changed to toxic one, now deal
with what happens if it has two symbols whose names differ only in case.
Because implementation must do the right thing because this is standard so
must be language-quality. But is completely unclear what the right thing
is at all in this case.
Much worse, we all want native threads (we have native threads so that is
good). So now can have two threads with different readtables and thus
*different cases for symbol names at the same time*. Only hope would be to
force symbols to have two name slots and SYMBOL-NAME would need to check
the current readtable to know which one to look up.
This is all fucked up, and it is fucked up because the readtable is machine
which tells reader which data to construct or find corresponding to input
stream. Is not a place to control what the names of existing symbols are
and using it for that is stupid.
Not using readtable but some other mechanism is better. But is still hard
if that new mechanism is dynamic at all: still probably need two name
slots, still have problems of mixed-case.
Also you keep going on about how it is inconvenient to deal with symbols
with mixed case (or lower case). Why don't you just solve that problem in
- write tiny function which takes package (CL for eg) and computes other
package with lowercase symbols, all symbols in new package have plist entry
pointing at their parents (or store mapping in table elsewhere does not
matter);
- write slightly less tiny function which walks over a form produces new
form with symbols with pointers to old symbols substituted;
- write wrappers for load / compile / compile-file / eval / repl which use
second function.
Now you have something you can use in lowercase. Hard bit is second
function: is easy to deal with most cases but array literals any other
object which might contain symbols in code need to be copied and this is
fiddly. But this is fine system does not need to be language-quality can
just not handle these cases and decide that you never do these things in
code you write.
First two of these took me ten mins with second fn explicitly not dealing
with complicated cases. Third part would be more fiddly (remember it only
has to work: does not need to be language-quality), mostly because would
need to understand enough of SLIME etc to make that work properly.
What you are doing sounds like standard displacement activity: 'I have
problem I need to solve which I could solve but I don't want to so I will
propose vast changes to language which I know will never happen so I have
excuse not to solve problem'. Used to be really common behaviour by people
on CLL, glad to see nothing has changed.
Sorry. I get it. Any change is bad.
Mart van de Wege
2020-09-27 14:34:43 UTC
Permalink
Post by Blake McBride
Sorry. I get it. Any change is bad.
Well, apparently any change that does not conform to what you want is,
yes.

Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
Manfred Bergmann
2020-09-27 18:52:46 UTC
Permalink
Post by Mart van de Wege
Sorry. I get it. Any change is bad.
Well, apparently any change that does not conform to what you want is,
yes.
Mart
I guess at some point one has to accept that change may be possible but the cost is too high.
CL doesn't seem to be designed for this, or changing it has an enormous impact.


Manfred
His Kennyness
2020-09-28 10:32:00 UTC
Permalink
The new mode is not for old code. Changing any of the modes on
pre-existing code is likely to mess it up.
Did you read what I wrote? Perhaps you read but obviously did not
understand. Is nothing to do with old code is to do with implementation.
If readtable controls case of symbol names then changing readtable may
require change in case of symbol names and thus implementation must check
for this every time readtable is changed. This means every call to SET,
every incantation of (SETF (SYMBOL-VALUE ...) ...) must now check for this
at least.
And implementation must, when readtable is changed to toxic one, now deal
with what happens if it has two symbols whose names differ only in case.
Because implementation must do the right thing because this is standard so
must be language-quality. But is completely unclear what the right thing
is at all in this case.
Much worse, we all want native threads (we have native threads so that is
good). So now can have two threads with different readtables and thus
*different cases for symbol names at the same time*. Only hope would be to
force symbols to have two name slots and SYMBOL-NAME would need to check
the current readtable to know which one to look up.
This is all fucked up, and it is fucked up because the readtable is machine
which tells reader which data to construct or find corresponding to input
stream. Is not a place to control what the names of existing symbols are
and using it for that is stupid.
Not using readtable but some other mechanism is better. But is still hard
if that new mechanism is dynamic at all: still probably need two name
slots, still have problems of mixed-case.
Also you keep going on about how it is inconvenient to deal with symbols
with mixed case (or lower case). Why don't you just solve that problem in
- write tiny function which takes package (CL for eg) and computes other
package with lowercase symbols, all symbols in new package have plist entry
pointing at their parents (or store mapping in table elsewhere does not
matter);
- write slightly less tiny function which walks over a form produces new
form with symbols with pointers to old symbols substituted;
- write wrappers for load / compile / compile-file / eval / repl which use
second function.
Now you have something you can use in lowercase. Hard bit is second
function: is easy to deal with most cases but array literals any other
object which might contain symbols in code need to be copied and this is
fiddly. But this is fine system does not need to be language-quality can
just not handle these cases and decide that you never do these things in
code you write.
First two of these took me ten mins with second fn explicitly not dealing
with complicated cases. Third part would be more fiddly (remember it only
has to work: does not need to be language-quality), mostly because would
need to understand enough of SLIME etc to make that work properly.
What you are doing sounds like standard displacement activity: 'I have
problem I need to solve which I could solve but I don't want to so I will
propose vast changes to language which I know will never happen so I have
excuse not to solve problem'. Used to be really common behaviour by people
on CLL, glad to see nothing has changed.
Amen. We should check to see if this is a regular autumnal ritual.

Is he gone?
Sorry. I get it. Any change is bad.
Oh. Well, it would be fun to hear more about why your specific problems using X to translate from a decent language like Scheme to a steaming turd like C# should provoke a rewrite of X.

I mean, if you could use X++ to deliver world peace, sure....

So why did you use CL instead of Scheme for this project?
none) (albert
2020-09-29 11:58:02 UTC
Permalink
Post by His Kennyness
Sorry. I get it. Any change is bad.
Oh. Well, it would be fun to hear more about why your specific problems
using X to translate from a decent language like Scheme to a steaming
turd like C# should provoke a rewrite of X.
C# is a non-compatible rewrite of C with the benefit of hindsight.
I find the changes sensible and easy to memorize.
After one day of study, it took me just a couple of days to write a gui
program that calculates organ pipe parameters, display the organ
pipes, output tables of how to cut wood pieces etc.
So I can't understand such a very pejorative rejecten of C#.
Is it just that is it in the C-family of languages?

Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
His Kennyness
2020-09-29 14:54:56 UTC
Permalink
Post by none) (albert
Post by His Kennyness
Sorry. I get it. Any change is bad.
Oh. Well, it would be fun to hear more about why your specific problems
using X to translate from a decent language like Scheme to a steaming
turd like C# should provoke a rewrite of X.
C# is a non-compatible rewrite of C with the benefit of hindsight.
I find the changes sensible and easy to memorize.
After one day of study, it took me just a couple of days to write a gui
program that calculates organ pipe parameters, display the organ
pipes, output tables of how to cut wood pieces etc.
So I can't understand such a very pejorative rejecten of C#.
Is it just that is it in the C-family of languages?
Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
Sorry, I was blaming the language for its motivation, viz., Bill Gates's attempt to monopolize all of computing when his little trick of hijacking Java was deemed illegal as well as evil.

You are the second person I know to rave on C#, I imagine it is fine. Easy to memorize beats the hell out of Clojure.

-hk
none) (albert
2020-09-30 15:30:34 UTC
Permalink
Post by His Kennyness
Post by none) (albert
Post by His Kennyness
Sorry. I get it. Any change is bad.
Oh. Well, it would be fun to hear more about why your specific problems
using X to translate from a decent language like Scheme to a steaming
turd like C# should provoke a rewrite of X.
C# is a non-compatible rewrite of C with the benefit of hindsight.
I find the changes sensible and easy to memorize.
After one day of study, it took me just a couple of days to write a gui
program that calculates organ pipe parameters, display the organ
pipes, output tables of how to cut wood pieces etc.
So I can't understand such a very pejorative rejecten of C#.
Is it just that is it in the C-family of languages?
Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
Sorry, I was blaming the language for its motivation, viz., Bill Gates's
attempt to monopolize all of computing when his little trick of
hijacking Java was deemed illegal as well as evil.
You are the second person I know to rave on C#, I imagine it is fine.
Easy to memorize beats the hell out of Clojure.
I don't rave on C#. I'm a supposedly allround professional and at the
time I was anticipating I might need C# on my resume.
At one time I needed perl on my resume, and I ported my pentium
assembler to perl, and attached it to the application.
Now calling perl a "steaming turd" is perfectly reasonable.
(And yes, no questions about my perl experience were asked,
though it was my first, and last, perl program ever. )

As much as I hate monopolization attempts, it doesn't get in the way
of my opinion about a language.
Post by His Kennyness
-hk
Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
His Kennyness
2020-09-30 15:35:46 UTC
Permalink
Post by none) (albert
Post by His Kennyness
Post by none) (albert
Post by His Kennyness
Sorry. I get it. Any change is bad.
Oh. Well, it would be fun to hear more about why your specific problems
using X to translate from a decent language like Scheme to a steaming
turd like C# should provoke a rewrite of X.
C# is a non-compatible rewrite of C with the benefit of hindsight.
I find the changes sensible and easy to memorize.
After one day of study, it took me just a couple of days to write a gui
program that calculates organ pipe parameters, display the organ
pipes, output tables of how to cut wood pieces etc.
So I can't understand such a very pejorative rejecten of C#.
Is it just that is it in the C-family of languages?
Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
Sorry, I was blaming the language for its motivation, viz., Bill Gates's
attempt to monopolize all of computing when his little trick of
hijacking Java was deemed illegal as well as evil.
You are the second person I know to rave on C#, I imagine it is fine.
Easy to memorize beats the hell out of Clojure.
I don't rave on C#. I'm a supposedly allround professional and at the
time I was anticipating I might need C# on my resume.
At one time I needed perl on my resume, and I ported my pentium
assembler to perl, and attached it to the application.
Now calling perl a "steaming turd" is perfectly reasonable.
(And yes, no questions about my perl experience were asked,
though it was my first, and last, perl program ever. )
As much as I hate monopolization attempts, it doesn't get in the way
of my opinion about a language.
You are absolutely right. Speaking of which, I am surprised to hear talk of folks abandoning that ReactJS because of Facebook's behavior in general. That seems like a catgory error.
Kaz Kylheku
2020-10-01 02:22:22 UTC
Permalink
Post by His Kennyness
You are absolutely right. Speaking of which, I am surprised to hear
talk of folks abandoning that ReactJS because of Facebook's behavior
in general. That seems like a catgory error.
If people need to rag on Facebook as a cover story for switching
to the reactive shiznit known as Cells, then let them rag on Facebook,
y'know?
--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1
His Kennyness
2020-10-01 02:25:36 UTC
Permalink
Post by Kaz Kylheku
Post by His Kennyness
You are absolutely right. Speaking of which, I am surprised to hear
talk of folks abandoning that ReactJS because of Facebook's behavior
in general. That seems like a catgory error.
If people need to rag on Facebook as a cover story for switching
to the reactive shiznit known as Cells, then let them rag on Facebook,
y'know?
--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1
I'm waiting with open arms! But it feels like Vue is going to inherit the mojo. Me, I am going after Flutter. There are only five state management options available for Flutter, so the field is wide open.
Manfred Bergmann
2020-09-22 19:15:39 UTC
Permalink
Okay. Clearly this is a non-starter.
How about baby steps. How about just #3? This should be relatively
easy, and it can be done by simply adding an option to readtable-case.
#4 is already happening in some implementations. (It is critical in
some instances because without it you're confined to a single processor.)
#5 and #6 are also partially done in many implementations. I just
thought standardizing this stuff may be helpful.
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?



Manfred
Madhu
2020-09-23 04:41:09 UTC
Permalink
Post by Manfred Bergmann
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?
The meaning of the word 'standard' has changed significantly from the
time of X3J13. Google (and other silicon valley capital setups) create
standards and pushes them through its paid "peers" even before they
publish a single implementation but nevertheless ensure the monopoly
Manfred Bergmann
2020-09-23 09:44:34 UTC
Permalink
Post by Madhu
Post by Manfred Bergmann
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?
The meaning of the word 'standard' has changed significantly from the
time of X3J13. Google (and other silicon valley capital setups) create
standards and pushes them through its paid "peers" even before they
publish a single implementation but nevertheless ensure the monopoly
I probably meant in regards to CL.
Who would be in charge of such a thing, to create a new standard?
I would think all the CL implementation implementers (SBCL, CCL, LispWorks, etc.) should all be in that boat?
If there can be something agreed upon, than that's a new standard I'd guess.
paul wallich
2020-09-23 13:00:39 UTC
Permalink
Post by Manfred Bergmann
Post by Madhu
Post by Manfred Bergmann
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?
The meaning of the word 'standard' has changed significantly from the
time of X3J13. Google (and other silicon valley capital setups) create
standards and pushes them through its paid "peers" even before they
publish a single implementation but nevertheless ensure the monopoly
I probably meant in regards to CL.
Who would be in charge of such a thing, to create a new standard?
I would think all the CL implementation implementers (SBCL, CCL, LispWorks, etc.) should all be in that boat?
If there can be something agreed upon, than that's a new standard I'd guess.
This is the other part of the conundrum: you're asking dozens/hundreds
of people with fulltime jobs already to either volunteer or be funded by
their companies to spend time hashing out every niggling detail of the
new language and then to create one or more implementations that people
may or may not use. The reason that the previous iterations happened was
that the people signing the checks said they were willing to pay, and
weren't willing to keep paying for the status quo. Without that, expect
maintenance/development work on existing implementations to stop for a
couple of years. This doesn't seem like a good tradeoff.

If I were king, I would probably focus first on documentation. Every
package/library should have full descriptions and worked-out examples
rather than just "read the source". That would let people in more
easily, and it would also make it clearer where the gaps are that need
to be filled. Then the most of the things people need/want could be
provided in the form of additional packages/libraries, and the remainder
that required changes to the base language would be obvious.

paul
Manfred Bergmann
2020-09-23 13:54:52 UTC
Permalink
Post by paul wallich
Post by Manfred Bergmann
Post by Madhu
Post by Manfred Bergmann
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?
The meaning of the word 'standard' has changed significantly from the
time of X3J13. Google (and other silicon valley capital setups) create
standards and pushes them through its paid "peers" even before they
publish a single implementation but nevertheless ensure the monopoly
I probably meant in regards to CL.
Who would be in charge of such a thing, to create a new standard?
I would think all the CL implementation implementers (SBCL, CCL, LispWorks, etc.) should all be in that boat?
If there can be something agreed upon, than that's a new standard I'd guess.
This is the other part of the conundrum: you're asking dozens/hundreds
I didn't ask for that. :)
I was just asking how a new 'standard' could actually be defined, and who would do that.
The original people who defined the standard are probably not around anymore (I mean in Common Lisp land).
Post by paul wallich
of people with fulltime jobs already to either volunteer or be funded by
their companies to spend time hashing out every niggling detail of the
new language and then to create one or more implementations that people
may or may not use.
Some of the 'asked' standard additions are already implemented: threads, sockets
Post by paul wallich
If I were king, I would probably focus first on documentation. Every
package/library should have full descriptions and worked-out examples
rather than just "read the source". That would let people in more
easily, and it would also make it clearer where the gaps are that need
That's what I also had pointed out.
That's one of the greatest barriers for beginners.
So there should be a consistent, non-geeky, modern looking,
documentation 'page' (maybe a web page or portal next to https://common-lisp.net)
that covers the language functions and quicklisp libraries.


Manfred
none) (albert
2020-09-23 15:13:22 UTC
Permalink
Post by Manfred Bergmann
Post by paul wallich
Post by Manfred Bergmann
Post by Madhu
Post by Manfred Bergmann
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?
The meaning of the word 'standard' has changed significantly from the
time of X3J13. Google (and other silicon valley capital setups) create
standards and pushes them through its paid "peers" even before they
publish a single implementation but nevertheless ensure the monopoly
I probably meant in regards to CL.
Who would be in charge of such a thing, to create a new standard?
I would think all the CL implementation implementers (SBCL, CCL,
LispWorks, etc.) should all be in that boat?
Post by paul wallich
Post by Manfred Bergmann
If there can be something agreed upon, than that's a new standard I'd guess.
This is the other part of the conundrum: you're asking dozens/hundreds
I didn't ask for that. :)
I was just asking how a new 'standard' could actually be defined, and who would do that.
The original people who defined the standard are probably not around
anymore (I mean in Common Lisp land).
Post by paul wallich
of people with fulltime jobs already to either volunteer or be funded by
their companies to spend time hashing out every niggling detail of the
new language and then to create one or more implementations that people
may or may not use.
Some of the 'asked' standard additions are already implemented: threads, sockets
Post by paul wallich
If I were king, I would probably focus first on documentation. Every
package/library should have full descriptions and worked-out examples
rather than just "read the source". That would let people in more
easily, and it would also make it clearer where the gaps are that need
That's what I also had pointed out.
That's one of the greatest barriers for beginners.
So there should be a consistent, non-geeky, modern looking,
documentation 'page' (maybe a web page or portal next to
https://common-lisp.net)
that covers the language functions and quicklisp libraries.
An example. I have installed clisp on my ubuntu system.
There are a few slides to get started.
Then I want an answer to the question, what special characters
are possible, hence forbidden in names, and hence a possible
pitfall, if I try lisp code from the old books I have.
The next step up in documentation is apparently the implementation
manual. I deemed it too much work learning to navigate it,
so I resort to experimenting.
Post by Manfred Bergmann
Manfred
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Paul Rubin
2020-09-23 18:00:13 UTC
Permalink
Post by none) (albert
There are a few slides to get started.
Then I want an answer to the question, what special characters
are possible, hence forbidden in names, and hence a possible
For this kind of thing you are best off starting out by reading a book
about CL. There are lots of them, some freely downloadable.
Tom Russ
2020-09-23 20:22:04 UTC
Permalink
Post by Paul Rubin
Post by none) (albert
There are a few slides to get started.
Then I want an answer to the question, what special characters
are possible, hence forbidden in names, and hence a possible
For this kind of thing you are best off starting out by reading a book
about CL. There are lots of them, some freely downloadable.
I generally agree, although for a definitive answer to a question about allowed
characters, one would generally need to consult a reference on the syntax of
identifiers. It is probably because most other languages have much more
restrictive identifier syntax rules that this may not be explained early in Lisp
texts.

But on the off chance that the OP still cares about the question, I will offer
two answers to this particular question:
(1) Quick rule of thumb: Any character except whitespace, vertical bar (|) and
backslash (\) can be in a name.
(2) Long answer: Any character at all, although whitespace, vertical bar and backslash
must be escaped to appear in a name. The two escape characters are backslash,
for single characters and paired vertical bars to escape all characters (except vertical
bars and backslashes) between them. You can still have verticals bars and backslashes
in identifiers but will need to use the backslash escape mechanism for them.

This gives you a lot of freedom, so it is actually legal to have lisp identifiers that have
whitespace, including linebreaks, in them. But it would be a bad idea to actually do that.

[If I were to speculate, this freedom is probably because early lisp systems did not have
string objects, so symbols were stand-ins for actual strings. And thus have rules similar
to what you find in strings in other programming languages. Although many of them
do not allow literal linebreaks in strings or have some special type of string like "raw
strings" that do allow them.]
none) (albert
2020-09-24 10:17:56 UTC
Permalink
Post by Tom Russ
Post by Paul Rubin
Post by none) (albert
There are a few slides to get started.
Then I want an answer to the question, what special characters
are possible, hence forbidden in names, and hence a possible
For this kind of thing you are best off starting out by reading a book
about CL. There are lots of them, some freely downloadable.
I generally agree, although for a definitive answer to a question about allowed
characters, one would generally need to consult a reference on the syntax of
identifiers. It is probably because most other languages have much more
restrictive identifier syntax rules that this may not be explained early in Lisp
texts.
But on the off chance that the OP still cares about the question, I will offer
(1) Quick rule of thumb: Any character except whitespace, vertical bar (|) and
backslash (\) can be in a name.
My guess is that the brackets '(' and ')' are on the list. I experimented and
found that '"' can't be used without the escape. Then there might be a comment
character. So my question had better be 'What are the characters a newbie
has to worry about'?
Of course if I wanted to program in the language I would just err on the
side of caution, and mandate char's digit's and underscores via the
local coding standard. But I'm interested in the language itself.
Post by Tom Russ
(2) Long answer: Any character at all, although whitespace, vertical bar and backslash
must be escaped to appear in a name. The two escape characters are backslash,
for single characters and paired vertical bars to escape all characters
(except vertical
bars and backslashes) between them. You can still have verticals bars and backslashes
in identifiers but will need to use the backslash escape mechanism for them.
This gives you a lot of freedom, so it is actually legal to have lisp identifiers that have
whitespace, including linebreaks, in them. But it would be a bad idea to actually do that.
[If I were to speculate, this freedom is probably because early lisp systems did not have
string objects, so symbols were stand-ins for actual strings. And thus have rules similar
to what you find in strings in other programming languages. Although many of them
do not allow literal linebreaks in strings or have some special type of string like "raw
strings" that do allow them.]
Okay. My starting point must be the man page statement:
"clisp is an implementation of ANSI[38] standard."
Now I can read either that standard (terrifying) or books about that
standard.
The implementation of scheme that I have installed has no such
statement, but a reference to texinfo, (that is not installed due
to the controversy between Stallman and Debian; Debian thinks
most info doc's are not "free") .

The explanation about identifiers is useful in its own right, but
I'm worried about what might happen around "macro's" or "hygienic macro's".
(That may be just the fear for the unknown.)

Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Paul Rubin
2020-09-24 17:02:16 UTC
Permalink
Post by none) (albert
My guess is that the brackets '(' and ')' are on the list. I
experimented and found that '"' can't be used without the escape.
Welcome to GNU CLISP 2.49.92 (2018-02-18) <http://clisp.org/>
[1]> '|(((((|
|(((((|

works for me. Similarly |||||.
Post by none) (albert
Post by Tom Russ
This gives you a lot of freedom, so it is actually legal to have lisp
identifiers that have whitespace, including linebreaks, in them. But
it would be a bad idea to actually do that.
Certainly in handwritten code that could be pretty strange. In machine
generated code such as something created inside a macro expansion, maybe
it could be ok.
Post by none) (albert
"clisp is an implementation of ANSI[38] standard."
Now I can read either that standard (terrifying) or books about that
standard.
I'm not sure that reading CLTL2 or the CL hyperspec is much different
from reading the standard.
Post by none) (albert
The explanation about identifiers is useful in its own right, but
I'm worried about what might happen around "macro's" or "hygienic macro's".
(That may be just the fear for the unknown.)
Unless I'm mistaken, CL doesn't have hygienic macros. Figuring out how
to do them is part of why it took so long to add macros to Scheme.
Paul Rubin
2020-09-24 17:11:43 UTC
Permalink
Post by Paul Rubin
works for me. Similarly |||||.
That was supposed to say: Similarly )))))
Sorry for any confusion.
paul wallich
2020-09-23 15:25:19 UTC
Permalink
Post by Manfred Bergmann
Post by paul wallich
Post by Manfred Bergmann
Post by Madhu
Post by Manfred Bergmann
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?
The meaning of the word 'standard' has changed significantly from the
time of X3J13. Google (and other silicon valley capital setups) create
standards and pushes them through its paid "peers" even before they
publish a single implementation but nevertheless ensure the monopoly
I probably meant in regards to CL.
Who would be in charge of such a thing, to create a new standard?
I would think all the CL implementation implementers (SBCL, CCL, LispWorks, etc.) should all be in that boat?
If there can be something agreed upon, than that's a new standard I'd guess.
This is the other part of the conundrum: you're asking dozens/hundreds
I didn't ask for that. :)
Sorry, that was the generic "you". (_man_ in german, _on_ in french,
more or less. _one_ in a formalistic version of english that almost no
one uses.)
Post by Manfred Bergmann
I was just asking how a new 'standard' could actually be defined, and who would do that.
The original people who defined the standard are probably not around anymore (I mean in Common Lisp land).
Post by paul wallich
of people with fulltime jobs already to either volunteer or be funded by
their companies to spend time hashing out every niggling detail of the
new language and then to create one or more implementations that people
may or may not use.
Some of the 'asked' standard additions are already implemented: threads, sockets
Oh, yes. Some/many of them in more than one way (which means that a
standards committee has to pick one, or pick something that's not quite
any existing implementation, or write a mealy-mouthed standard that
allows all of the more important implementations to claim they conform.)
And then handle the details of incorporating it officially into the
language instead of unofficially...
Post by Manfred Bergmann
Post by paul wallich
If I were king, I would probably focus first on documentation. Every
package/library should have full descriptions and worked-out examples
rather than just "read the source". That would let people in more
easily, and it would also make it clearer where the gaps are that need
That's what I also had pointed out.
That's one of the greatest barriers for beginners.
So there should be a consistent, non-geeky, modern looking,
documentation 'page' (maybe a web page or portal next to https://common-lisp.net)
that covers the language functions and quicklisp libraries.
I wouldn't even care if it didn't look particularly modern as long as it
was all there. On the few occasions when I still use Lisp, I spend way
too much time reading the hyperspec with my language lawyer hat on.

paul
Manfred Bergmann
2020-09-23 16:07:01 UTC
Permalink
Post by paul wallich
Post by Manfred Bergmann
That's what I also had pointed out.
That's one of the greatest barriers for beginners.
So there should be a consistent, non-geeky, modern looking,
documentation 'page' (maybe a web page or portal next to https://common-lisp.net)
that covers the language functions and quicklisp libraries.
I wouldn't even care if it didn't look particularly modern as long as it
was all there. On the few occasions when I still use Lisp, I spend way
too much time reading the hyperspec with my language lawyer hat on.
paul
Btw: I just come across this one.
Not so bad actually.
Though it doesn't 'translate' the hyperspec.
But it's open source, anyone can contribute.
https://lamberta.github.io/minispec/index.html
Blake McBride
2020-09-26 15:29:03 UTC
Permalink
Post by paul wallich
Post by Manfred Bergmann
Post by Madhu
Post by Manfred Bergmann
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?
The meaning of the word 'standard' has changed significantly from the
time of X3J13. Google (and other silicon valley capital setups) create
standards and pushes them through its paid "peers" even before they
publish a single implementation but nevertheless ensure the monopoly
I probably meant in regards to CL.
Who would be in charge of such a thing, to create a new standard?
I would think all the CL implementation implementers (SBCL, CCL,
LispWorks, etc.) should all be in that boat?
If there can be something agreed upon, than that's a new standard I'd guess.
This is the other part of the conundrum: you're asking dozens/hundreds
of people with fulltime jobs already to either volunteer or be funded by
their companies to spend time hashing out every niggling detail of the
new language and then to create one or more implementations that people
may or may not use. The reason that the previous iterations happened was
that the people signing the checks said they were willing to pay, and
weren't willing to keep paying for the status quo. Without that, expect
maintenance/development work on existing implementations to stop for a
couple of years. This doesn't seem like a good tradeoff.
Yes, this may be the crux of it.
Azathoth Hastur
2020-10-11 21:21:41 UTC
Permalink
Post by Madhu
Post by Manfred Bergmann
A standardization might be helpful, with reference implementations.
But how would this work? Who can create a new standard?
The meaning of the word 'standard' has changed significantly from the
time of X3J13. Google (and other silicon valley capital setups) create
standards and pushes them through its paid "peers" even before they
publish a single implementation but nevertheless ensure the monopoly
usury

google is a banking scam based on the ad money scam jsut printing money never earned

not techincally powerful at all
Azathoth Hastur
2020-10-11 21:01:22 UTC
Permalink
Post by Blake McBride
Okay. Clearly this is a non-starter.
How about baby steps. How about just #3? This should be relatively
easy, and it can be done by simply adding an option to readtable-case.
#4 is already happening in some implementations. (It is critical in
some instances because without it you're confined to a single processor.)
#5 and #6 are also partially done in many implementations. I just
thought standardizing this stuff may be helpful.
Blake
Post by Blake McBride
Greetings,
Common Lisp is getting old.  Technology marches on.  I think a
1. Functions and variables share the same namespace
2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.
3. Change to a mixed-case language.  The base language is lower-case.
4. Support real / native threads
5. Properly handle tail recursion
6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension.
These are just a few ideas.  I think others can come up with more.
Although some of Common Lisp's functions are ugly with awkward
parameters, I think they're good enough for the most part and should be
left as-is so as not to change the language anymore than is necessary.
Blake McBride
How about simply learn how to use lisp as is?
Philip K.
2020-09-23 10:40:24 UTC
Permalink
Post by Blake McBride
Greetings,
Common Lisp is getting old. Technology marches on. I think a
1. Functions and variables share the same namespace
2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.
3. Change to a mixed-case language. The base language is lower-case.
4. Support real / native threads
5. Properly handle tail recursion
6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension.
These are just a few ideas. I think others can come up with more.
Although some of Common Lisp's functions are ugly with awkward
parameters, I think they're good enough for the most part and should
be left as-is so as not to change the language anymore than is
necessary.
Blake McBride
Wouldn't this basically just turn CL into Scheme?
--
Philip K.
Blake McBride
2020-09-24 20:53:34 UTC
Permalink
Post by Philip K.
Post by Blake McBride
Greetings,
Common Lisp is getting old. Technology marches on. I think a
1. Functions and variables share the same namespace
2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.
3. Change to a mixed-case language. The base language is lower-case.
4. Support real / native threads
5. Properly handle tail recursion
6. Improve on the ability to interact with the OS (sockets, etc.) -
perhaps as an extension.
These are just a few ideas. I think others can come up with more.
Although some of Common Lisp's functions are ugly with awkward
parameters, I think they're good enough for the most part and should
be left as-is so as not to change the language anymore than is
necessary.
Blake McBride
Wouldn't this basically just turn CL into Scheme?
No.

First, Scheme is a toy/learning language and is missing many, many
needed features.

Second, Scheme has many problems of its own. See
http://wiki.arahant.com/Wiki.jsp?page=Scheme-problems

Third, there are many other differences between CL and Scheme that I do
not think are good to change.

Blake McBride
George Neuner
2020-09-25 02:05:38 UTC
Permalink
On Thu, 24 Sep 2020 15:53:34 -0500, Blake McBride
Post by Blake McBride
First, Scheme is a toy/learning language and is missing many, many
needed features.
Only if you ignore libraries. There are several heavyweight Scheme
implementations that come with "batteries included".
Post by Blake McBride
Second, Scheme has many problems of its own. See
http://wiki.arahant.com/Wiki.jsp?page=Scheme-problems
NIL(null) vs #F is a valid objection.

Unspecified return is a straw man.

The other objections simply are obsolete / wrong. All the heavyweight
Scheme implementations support modules, libraries, objects, and
Lisp-like environment capturing macros (in addition to Scheme's
required hygienic macros). They also support threads, networking, and
abstract filesystems. A couple have platform independent GUIs as
well.

You may rightfully object that these things are not standardized as in
Lisp, but that is a different argument.
Post by Blake McBride
Third, there are many other differences between CL and Scheme that I do
not think are good to change.
Blake McBride
George
Zyni Moë
2020-09-25 09:51:13 UTC
Permalink
Post by George Neuner
Unspecified return is a straw man.
But remember straw man is *purpose* here. Person has problem. Problem can
be solved pretty easy (you want threads, they are there, is standard
('substandard' in KMP terms need to find that article) interface to
threads. Want to deal with lowercase, take you a few days to do that
conveniently perhaps in non-language-quality way as described in other
article. But person does not really want to solve problem: person wants to
erect plan for huge straw edifice which can never be built (new standard)
so problem will never be solved.

This is just standard displacement activity. Is what people do. Is what I
do. You are not good at guitar well obviously this is because you do not
have very expensive very beautiful guitar which famous jazz player used if
you have that you will be able to be famous jazz player too. Never mind
you already have pretty expensive guitar: really expensive guitar (and must
be old one from right era like famous player used) will fix it. Will not:
*practicing* will fix it; practicing is how famous jazz player got to be
good and famous. Same thing is going on here: problem is soluble pretty
easily but is better to make plans for vast straw city which will never be
built.
--
the small snake
George Neuner
2020-09-26 19:17:12 UTC
Permalink
On Fri, 25 Sep 2020 09:51:13 -0000 (UTC), Zyni Moë
Post by Zyni Moë
Post by George Neuner
Unspecified return is a straw man.
But remember straw man is *purpose* here. Person has problem. Problem can
be solved pretty easy (you want threads, they are there, is standard
('substandard' in KMP terms need to find that article) interface to
threads. Want to deal with lowercase, take you a few days to do that
conveniently perhaps in non-language-quality way as described in other
article. But person does not really want to solve problem: person wants to
erect plan for huge straw edifice which can never be built (new standard)
so problem will never be solved.
8-)

Obviously, because the basis of the objection is that idiomatic Lisp
code doesn't (necessarily) work in Scheme.

I'd say "duh" but it would be redundant.
Post by Zyni Moë
This is just standard displacement activity. Is what people do. Is what I
do. You are not good at guitar well obviously this is because you do not
have very expensive very beautiful guitar which famous jazz player used if
you have that you will be able to be famous jazz player too. Never mind
you already have pretty expensive guitar: really expensive guitar (and must
*practicing* will fix it; practicing is how famous jazz player got to be
good and famous. Same thing is going on here: problem is soluble pretty
easily but is better to make plans for vast straw city which will never be
built.
+1


George
Blake McBride
2020-09-26 21:20:16 UTC
Permalink
Post by George Neuner
On Thu, 24 Sep 2020 15:53:34 -0500, Blake McBride
Post by Blake McBride
First, Scheme is a toy/learning language and is missing many, many
needed features.
Only if you ignore libraries. There are several heavyweight Scheme
implementations that come with "batteries included".
Problem is the batteries from one Scheme doesn't fit the others.
Post by George Neuner
Post by Blake McBride
Second, Scheme has many problems of its own. See
http://wiki.arahant.com/Wiki.jsp?page=Scheme-problems
NIL(null) vs #F is a valid objection.
Unspecified return is a straw man.
The other objections simply are obsolete / wrong. All the heavyweight
Scheme implementations support modules, libraries, objects, and
Lisp-like environment capturing macros (in addition to Scheme's
required hygienic macros). They also support threads, networking, and
abstract filesystems. A couple have platform independent GUIs as
well.
Again, if you use one implementation's module, libraries, objects, etc.,
they're utterly unportable.
Post by George Neuner
You may rightfully object that these things are not standardized as in
Lisp, but that is a different argument.
Post by Blake McBride
Third, there are many other differences between CL and Scheme that I do
not think are good to change.
Blake McBride
George
Zyni Moë
2020-09-25 09:48:42 UTC
Permalink
Post by Blake McBride
First, Scheme is a toy/learning language and is missing many, many
needed features.
Racket. Yes understand that people (inc me) worry about Racket direction
of travel, and that it is single-implementation language (instance not
class). But so are Python Perl Ruby Swift Go blah effectively: can live
with single imp.

And have deployed binaries using Racket which do critical system things.
Use Racket to produce plots from numerical simulation package ( package
written in CL but data interchange by csv, was not smart decision) because
was easier and more flexible than Python plotting.

Racket is not small, is not missing many features (fucking huge package
library) If you want to solve problem rather than complain Racket is fine.
Same as CL actually: CL is small toy language missing many features, but CL
*implementation* + Quicklisp which is what everyone uses is not.
--
the small snake
Blake McBride
2020-09-26 15:42:12 UTC
Permalink
Post by Zyni Moë
Post by Blake McBride
First, Scheme is a toy/learning language and is missing many, many
needed features.
Racket. Yes understand that people (inc me) worry about Racket direction
of travel, and that it is single-implementation language (instance not
class). But so are Python Perl Ruby Swift Go blah effectively: can live
with single imp.
And have deployed binaries using Racket which do critical system things.
Use Racket to produce plots from numerical simulation package ( package
written in CL but data interchange by csv, was not smart decision) because
was easier and more flexible than Python plotting.
Racket is not small, is not missing many features (fucking huge package
library) If you want to solve problem rather than complain Racket is fine.
Same as CL actually: CL is small toy language missing many features, but CL
*implementation* + Quicklisp which is what everyone uses is not.
Besides what you have mentioned and other things:

1. Racket is still single (real) threading. This means it only uses a
single core on a multi-core processor. These days, this is a
non-starter (at least for me).

2. I didn't see Lisp-style macros in Racket. I think Scheme macros are
awful for reasons I've written about elsewhere.

Blake
George Neuner
2020-09-26 20:08:30 UTC
Permalink
On Sat, 26 Sep 2020 10:42:12 -0500, Blake McBride
Post by Blake McBride
Post by Zyni Moë
Post by Blake McBride
First, Scheme is a toy/learning language and is missing many, many
needed features.
Racket. Yes understand that people (inc me) worry about Racket direction
of travel, and that it is single-implementation language (instance not
class). But so are Python Perl Ruby Swift Go blah effectively: can live
with single imp.
And have deployed binaries using Racket which do critical system things.
Use Racket to produce plots from numerical simulation package ( package
written in CL but data interchange by csv, was not smart decision) because
was easier and more flexible than Python plotting.
Racket is not small, is not missing many features (fucking huge package
library) If you want to solve problem rather than complain Racket is fine.
Same as CL actually: CL is small toy language missing many features, but CL
*implementation* + Quicklisp which is what everyone uses is not.
1. Racket is still single (real) threading. This means it only uses a
single core on a multi-core processor. These days, this is a
non-starter (at least for me).
You are being tripped up by terminology: Racket calls its kernel
threads "places". Places are (mostly) non-sharing CSP ala Hoare. What
Racket calls "threads" are green / userspace, multiplexed on a place.
[The main kernel thread of the application is itself a place, but by
convention "place" terminology is reserved for when there are multiple
places involved.]

Racket also has futures, which ... given sufficiently non-interfering
computations (some stupid things can F_ it up) ... will be executed in
parallel by a pool of background kernel threads.


https://docs.racket-lang.org/guide/concurrency.html

https://docs.racket-lang.org/guide/parallelism.html
Post by Blake McBride
2. I didn't see Lisp-style macros in Racket. I think Scheme macros are
awful for reasons I've written about elsewhere.
https://docs.racket-lang.org/compatibility/defmacro.html
Post by Blake McBride
Blake
Don't feel bad for missing these things - Racket's documentation is
enormous (many 1000s of pages) ... reading it all is just impractical.
I've been using Racket for many years (and its predecessor PLT Scheme
for years before that), but almost weekly there is mention in the
newsgroups of some Racket feature of which I was previously unaware.

The documentation is comprehensively indexed, but in reality you have
to have a pretty good idea of what terms to search for if you hope to
find much. And the documentations is split between a reference manual
and a "guide", with the guide defining much of the terminology used in
the reference.

Its more than a bit complicated 8-) On the plus side, the developers
are continually working to make the documentation more comprehensible
and easier to navigate.


George
Blake McBride
2020-09-26 21:17:29 UTC
Permalink
Post by George Neuner
On Sat, 26 Sep 2020 10:42:12 -0500, Blake McBride
Post by Blake McBride
Post by Zyni Moë
Post by Blake McBride
First, Scheme is a toy/learning language and is missing many, many
needed features.
Racket. Yes understand that people (inc me) worry about Racket direction
of travel, and that it is single-implementation language (instance not
class). But so are Python Perl Ruby Swift Go blah effectively: can live
with single imp.
And have deployed binaries using Racket which do critical system things.
Use Racket to produce plots from numerical simulation package ( package
written in CL but data interchange by csv, was not smart decision) because
was easier and more flexible than Python plotting.
Racket is not small, is not missing many features (fucking huge package
library) If you want to solve problem rather than complain Racket is fine.
Same as CL actually: CL is small toy language missing many features, but CL
*implementation* + Quicklisp which is what everyone uses is not.
1. Racket is still single (real) threading. This means it only uses a
single core on a multi-core processor. These days, this is a
non-starter (at least for me).
You are being tripped up by terminology: Racket calls its kernel
threads "places". Places are (mostly) non-sharing CSP ala Hoare. What
Racket calls "threads" are green / userspace, multiplexed on a place.
[The main kernel thread of the application is itself a place, but by
convention "place" terminology is reserved for when there are multiple
places involved.]
Racket also has futures, which ... given sufficiently non-interfering
computations (some stupid things can F_ it up) ... will be executed in
parallel by a pool of background kernel threads.
https://docs.racket-lang.org/guide/concurrency.html
https://docs.racket-lang.org/guide/parallelism.html
Your comments notwithstanding, I have an 8-core processor. Racket can
only use one.
Post by George Neuner
Post by Blake McBride
2. I didn't see Lisp-style macros in Racket. I think Scheme macros are
awful for reasons I've written about elsewhere.
https://docs.racket-lang.org/compatibility/defmacro.html
From their docs: "Important: Although define-macro is non-hygienic, it
is still restricted by Racket’s phase separation rules."
Post by George Neuner
Post by Blake McBride
Blake
Don't feel bad for missing these things - Racket's documentation is
enormous (many 1000s of pages) ... reading it all is just impractical.
I've been using Racket for many years (and its predecessor PLT Scheme
for years before that), but almost weekly there is mention in the
newsgroups of some Racket feature of which I was previously unaware.
The documentation is comprehensively indexed, but in reality you have
to have a pretty good idea of what terms to search for if you hope to
find much. And the documentations is split between a reference manual
and a "guide", with the guide defining much of the terminology used in
the reference.
Its more than a bit complicated 8-) On the plus side, the developers
are continually working to make the documentation more comprehensible
and easier to navigate.
Racket compiles to its own VM. Not terribly fast. No image
dump/restore. The language is utterly ad hoc. Not interested.

Blake
George Neuner
2020-09-27 00:08:11 UTC
Permalink
On Sat, 26 Sep 2020 16:17:29 -0500, Blake McBride
Post by Blake McBride
Post by George Neuner
On Sat, 26 Sep 2020 10:42:12 -0500, Blake McBride
Post by Blake McBride
Post by Zyni Moë
Post by Blake McBride
First, Scheme is a toy/learning language and is missing many, many
needed features.
Racket. Yes understand that people (inc me) worry about Racket direction
of travel, and that it is single-implementation language (instance not
class). But so are Python Perl Ruby Swift Go blah effectively: can live
with single imp.
And have deployed binaries using Racket which do critical system things.
Use Racket to produce plots from numerical simulation package ( package
written in CL but data interchange by csv, was not smart decision) because
was easier and more flexible than Python plotting.
Racket is not small, is not missing many features (fucking huge package
library) If you want to solve problem rather than complain Racket is fine.
Same as CL actually: CL is small toy language missing many features, but CL
*implementation* + Quicklisp which is what everyone uses is not.
1. Racket is still single (real) threading. This means it only uses a
single core on a multi-core processor. These days, this is a
non-starter (at least for me).
You are being tripped up by terminology: Racket calls its kernel
threads "places". Places are (mostly) non-sharing CSP ala Hoare. What
Racket calls "threads" are green / userspace, multiplexed on a place.
[The main kernel thread of the application is itself a place, but by
convention "place" terminology is reserved for when there are multiple
places involved.]
Racket also has futures, which ... given sufficiently non-interfering
computations (some stupid things can F_ it up) ... will be executed in
parallel by a pool of background kernel threads.
https://docs.racket-lang.org/guide/concurrency.html
https://docs.racket-lang.org/guide/parallelism.html
Your comments notwithstanding, I have an 8-core processor. Racket can
only use one.
Wrong!

A "place" is an OS *KERNEL* thread. Racket does NOT limit either
process or kernel thread affinity, so if the OS schedules across
multiple cores, an application written to use place WILL use multiple
cores.

Racket "threads" are in userspace and are multiplexed on a single
place, but each place can execute its own set of threads.


There is a further distinction between DYNAMIC (kernel thread) places
and DISTRIBUTED (separate process) places. You can use either or
both.

George
Blake McBride
2020-09-26 21:25:08 UTC
Permalink
Post by George Neuner
On Sat, 26 Sep 2020 10:42:12 -0500, Blake McBride
Post by Blake McBride
Post by Zyni Moë
Post by Blake McBride
First, Scheme is a toy/learning language and is missing many, many
needed features.
Racket. Yes understand that people (inc me) worry about Racket direction
of travel, and that it is single-implementation language (instance not
class). But so are Python Perl Ruby Swift Go blah effectively: can live
with single imp.
And have deployed binaries using Racket which do critical system things.
Use Racket to produce plots from numerical simulation package ( package
written in CL but data interchange by csv, was not smart decision) because
was easier and more flexible than Python plotting.
Racket is not small, is not missing many features (fucking huge package
library) If you want to solve problem rather than complain Racket is fine.
Same as CL actually: CL is small toy language missing many features, but CL
*implementation* + Quicklisp which is what everyone uses is not.
1. Racket is still single (real) threading. This means it only uses a
single core on a multi-core processor. These days, this is a
non-starter (at least for me).
You are being tripped up by terminology: Racket calls its kernel
threads "places". Places are (mostly) non-sharing CSP ala Hoare. What
Racket calls "threads" are green / userspace, multiplexed on a place.
[The main kernel thread of the application is itself a place, but by
convention "place" terminology is reserved for when there are multiple
places involved.]
Racket also has futures, which ... given sufficiently non-interfering
computations (some stupid things can F_ it up) ... will be executed in
parallel by a pool of background kernel threads.
https://docs.racket-lang.org/guide/concurrency.html
https://docs.racket-lang.org/guide/parallelism.html
I'm not being "tripped up". From their docs:

"Threads run concurrently in the sense that one thread can preempt
another without its cooperation, but threads do not run in parallel in
the sense of using multiple hardware processors."
Post by George Neuner
Post by Blake McBride
2. I didn't see Lisp-style macros in Racket. I think Scheme macros are
awful for reasons I've written about elsewhere.
https://docs.racket-lang.org/compatibility/defmacro.html
From their docs: "Although define-macro is non-hygienic, it is still
restricted by Racket’s phase separation rules."
Post by George Neuner
Post by Blake McBride
Blake
Don't feel bad for missing these things - Racket's documentation is
enormous (many 1000s of pages) ... reading it all is just impractical.
I've been using Racket for many years (and its predecessor PLT Scheme
for years before that), but almost weekly there is mention in the
newsgroups of some Racket feature of which I was previously unaware.
The documentation is comprehensively indexed, but in reality you have
to have a pretty good idea of what terms to search for if you hope to
find much. And the documentations is split between a reference manual
and a "guide", with the guide defining much of the terminology used in
the reference.
Its more than a bit complicated 8-) On the plus side, the developers
are continually working to make the documentation more comprehensible
and easier to navigate.
Again, Racket is an ad hoc language that could be dropped tomorrow.
Even if it remains, lack of true support for threads and macros is a
non-starter for me.

Blake
Post by George Neuner
George
George Neuner
2020-09-27 00:10:09 UTC
Permalink
On Sat, 26 Sep 2020 16:25:08 -0500, Blake McBride
Post by Blake McBride
Post by George Neuner
https://docs.racket-lang.org/guide/concurrency.html
https://docs.racket-lang.org/guide/parallelism.html
"Threads run concurrently in the sense that one thread can preempt
another without its cooperation, but threads do not run in parallel in
the sense of using multiple hardware processors."
And I can deduce from your comment that you did not bother to read the
page on parallelism.

George
steve
2021-07-12 00:31:42 UTC
Permalink
Post by Blake McBride
Greetings,
Common Lisp is getting old.
we all die sometime.
Post by Blake McBride
Technology marches on. I think a significant
1. Functions and variables share the same namespace
huh?
Post by Blake McBride
2. Remove all of the Common Lisp function-specific functions that end
up as duplicates because of #1.
huh?
Post by Blake McBride
3. Change to a mixed-case language. The base language is lower-case.
Ummm. that was 20 years ago.
Post by Blake McBride
4. Support real / native threads
yeah, they were called coprocesses until ...
Post by Blake McBride
5. Properly handle tail recursion
you must be kidding.
Post by Blake McBride
6. Improve on the ability to interact with the OS (sockets, etc.) - perhaps as
an extension.
This I agree with! POSIX!
Post by Blake McBride
These are just a few ideas. I think others can come up with more.
Although some of Common Lisp's functions are ugly with awkward parameters, I
think they're good enough for the most part and should be left as-is so as not
to change the language anymore than is necessary.
Yeah, lisp is like getting old.

Loading...