Earlier quoted context omitted.
> What is the argument against calling it print? No one is suggesting fprintf by the way. Very simple, actually. You know the term REPL, right? It stands for Read-Eval-Print Loop, and originates with Lisp. Actually, every Lisp gives you read, eval and print functions which work closely together. In particular, you expect read to be able to understand what print outputs, because they work in a loop. So print is alread…
> You know the term REPL, right? Yes, and notice how it doesn't stand for Rrepl-Evl-Princ Loop. > There is a good rationale behind those names. No, there is a good rationale for having separate functions, there is no logical rationale for prin1, princ and pprint. Let's take "prin1 produces output suitable for input to read." from the link you provided. Since we are redesigning the language anyway, let's call that eva…
CL21: An experimental project redesigning Common Lisp
51–60 of 102 posts
Re: CL21: An experimental project redesigning Common Lisp
#52This looks cool enough but it would need a big community to really change the common lisp landscape (in my opinion). I wonder how the lazy sequence support stacks up to Clojure, Haskell, etc. support. One difficulty with promoting a more modern layer to common lisp is that Clojure is already such a productive and practical language. I have written a few common lisp books, and remain a fan of the language, and an upgr…
Re: CL21: An experimental project redesigning Common Lisp
#53Re: CL21: An experimental project redesigning Common Lisp
#54Earlier quoted context omitted.
As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be…
Ah, but how would you easily access the number 6 out of the nested list '((((5 4 3 2 1) 6) 7) 8 9) without one of the cute compositions of "car" and "cdr"? In this case, "cadaar". (Rhetorical question. "car" and "cdr" are neat for their cute composition, but I would never inflict that on someone first learning the language.)
(def x ((((5 4 3 2 1) 6) 7) 8 9))
(get-in x (0 0 0 1))
Probably botched quoting, don't know common lisp, only clojure.Re: CL21: An experimental project redesigning Common Lisp
#55Earlier quoted context omitted.
As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be…
Ah, but how would you easily access the number 6 out of the nested list '((((5 4 3 2 1) 6) 7) 8 9) without one of the cute compositions of "car" and "cdr"? In this case, "cadaar". (Rhetorical question. "car" and "cdr" are neat for their cute composition, but I would never inflict that on someone first learning the language.)
Re: CL21: An experimental project redesigning Common Lisp
#56This looks cool enough but it would need a big community to really change the common lisp landscape (in my opinion). I wonder how the lazy sequence support stacks up to Clojure, Haskell, etc. support. One difficulty with promoting a more modern layer to common lisp is that Clojure is already such a productive and practical language. I have written a few common lisp books, and remain a fan of the language, and an upgr…
I can understand the reasons why people prefer to target the CLR/JVM/LLVM/BEAM/Name-your-favorite-vm but I yearn for more compiled-to-native-languages such as Golang. As attractive as partially-compiled/interpretated languages are, I simply do not enjoy creating programs in a language that can be decompiled to source so easily. We need more languages that have decent performance instead of having to drop down to poin…
Re: CL21: An experimental project redesigning Common Lisp
#57Earlier quoted context omitted.
Ah, but how would you easily access the number 6 out of the nested list '((((5 4 3 2 1) 6) 7) 8 9) without one of the cute compositions of "car" and "cdr"? In this case, "cadaar". (Rhetorical question. "car" and "cdr" are neat for their cute composition, but I would never inflict that on someone first learning the language.)
One word: lenses.
Re: CL21: An experimental project redesigning Common Lisp
#58Earlier quoted context omitted.
As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be…
I know and agree, but they have some weird syntactic/linguistic quality: - both 3 letters each - only differ by 1 letter a|d None of the alternatives have these symmetry, and it (very subjectively) shows in the code.
Re: CL21: An experimental project redesigning Common Lisp
#59Earlier quoted context omitted.
So in 2020 people will have forgotten the etymology of print or format, rendering them nearly meaningless while princ, car and cdr endure? That's rhetorical, you don't need to reply.
So you think we're better off just giving up on a perfectly good reason for these naming conventions and call "princ" "print" just because some poor language without the concept of Read-Eval-Print Loop named its function that way and then everyone else blindly followed? Seriously, Lisp has long history and had half the "new amazing features of today" 30 years ago. There is a rationale for naming conventions. Just bec…
Just because CL has a long history, it doesn't mean that everything about it has to be correct. Otherwise why start a project of CL remodernization in the first place?
Re: CL21: An experimental project redesigning Common Lisp
#60One of the things I don't like about Common Lisp is the unusual names. Just on the basis of the linked page, CL21 doesn't fix that. Take princ #"Hello, ${name}\n". Why not just use print like the rest of the programming world. Okay, some languages use writeln, etc. But princ? Why not print? A little further down, we see while-let1. Why the number? If you want to call it "Common Lisp in the 21st Century" you need to c…
If I were doing this I'd also get rid of the * around the hash keyword and either just go with the keyword 'hash' or replace it all together with an operator.
It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names.
Why not switch the parens to something that's a single keystroke? Why not get rid of the parens in most cases? In some cases this seems to make the parens problem with lisp even worse?
(loop for key being each hash-key of *hash*
using (hash-value val)
when (
with 5 sets of parens turns into (doeach ((key val) *hash*)
(when (
six setsthe former also required fewer shift-character keystroke combinations
( ) *
while the new syntax ends up with ( ) *
this feels like my hands are wrestling, not typingthis just seems to be moving things around, not really improving anything
I'm not a lisper, so somebody correct me if I'm wrong