Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CL21: An experimental project redesigning Common Lisp

cl21.org

Post reply on HN
Print view View original

61–70 of 102 posts

Re: CL21: An experimental project redesigning Common Lisp

#61

Post by agentultra »

Immortalin wrote: post #52
mark_l_watson wrote: post #2

This 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…

Some Common Lisp implementations do compile down to machine code. An example of one I'm told is quite good is SBCL:

  * (disassemble #'(lambda () (loop for i from 1 upto 10 summing i)))
  
  ; disassembly for (LAMBDA ())
  ; Size: 62 bytes. Origin: #x100306FE84
  ; 84:       BB02000000       MOV EBX, 2                       ; no-arg-parsing entry point
  ; 89:       31C9             XOR ECX, ECX
  ; 8B:       EB21             JMP L1
  ; 8D:       0F1F00           NOP
  ; 90: L0:   48895DF8         MOV [RBP-8], RBX
  ; 94:       488BD1           MOV RDX, RCX
  ; 97:       488BFB           MOV RDI, RBX
  ; 9A:       41BBA0010020     MOV R11D, 536871328              ; GENERIC-+
  ; A0:       41FFD3           CALL R11
  ; A3:       488BCA           MOV RCX, RDX
  ; A6:       488B5DF8         MOV RBX, [RBP-8]
  ; AA:       4883C302         ADD RBX, 2
  ; AE: L1:   4883FB14         CMP RBX, 20
  ; B2:       7EDC             JLE L0
  ; B4:       488BD1           MOV RDX, RCX
  ; B7:       488BE5           MOV RSP, RBP
  ; BA:       F8               CLC
  ; BB:       5D               POP RBP
  ; BC:       C3               RET
  ; BD:       CC0A             BREAK 10                         ; error trap
  ; BF:       02               BYTE #X02
  ; C0:       19               BYTE #X19                        ; INVALID-ARG-COUNT-ERROR
  ; C1:       9A               BYTE #X9A                        ; RCX
Keep in mind that's with full run-time type checking and other nice debugging features. You can hint the compiler to turn these things off in your hardened code sections for even smaller, tighter code.

Re: CL21: An experimental project redesigning Common Lisp

#62

Post by Moyamo »

agentultra wrote: post #61
Immortalin wrote: post #52

Earlier quoted context omitted.

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…

Some Common Lisp implementations do compile down to machine code. An example of one I'm told is quite good is SBCL: * (disassemble #'(lambda () (loop for i from 1 upto 10 summing i))) ; disassembly for (LAMBDA ()) ; Size: 62 bytes. Origin: #x100306FE84 ; 84: BB02000000 MOV EBX, 2 ; no-arg-parsing entry point ; 89: 31C9 XOR ECX, ECX ; 8B: EB21 JMP L1 ; 8D: 0F1F00 NOP ; 90: L0: 48895DF8 MOV [RBP-8], RBX ; 94: 488BD1 MO…

I think the parent comment about VMs was aimed at clojure.

Re: CL21: An experimental project redesigning Common Lisp

#63

Post by _femp »

jwr wrote: post #14

As a former common lisper, I don't see the point. Clojure is better in pretty much every respect and incorporates many fresh ideas (such as excellent concurrency support). Syntax is the least of CL's limitations. I didn't switch to Clojure because it was "easy" (quite the contrary). And no, I do not miss reader macros. Perhaps more surprisingly, I don't miss CLOS at all, much as I always admired its design. It's just…

Clojure lacks a formal spec, commercial vendor support, and doesn't have the long track record of CL. Clojure also requires JVM issues to be considered (e.g., which JVM will you use?). Don't know about C FFI with Clojure, but perhaps that's another CL advantage?

For many, Clojure may be a better choice as you suggest: perhaps especially for web projects. But I think for some groups and applications, CL remains a better choice.

Re: CL21: An experimental project redesigning Common Lisp

#64

Post by agentultra »

bane wrote: post #60
bachmeier wrote: post #4

One 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…

Yeah, lots of this is just swapping out one awkward keyword for another. 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 ke…

> Yeah, lots of this is just swapping out one awkward keyword for another.

Many a well-intentioned Lisper eventually begins to see deficiencies where there are none and attempts to improve their implementation of choice. Common Lisp is one such target because people coming from in-vogue languages are used to the language changing every year or two. Invariably this leads to superficial changes at best which are enabled, surprise of surprises, by Common Lisp because it was designed to be extensible.

My theory is that if your language of choice needs to change its grammar rules to introduce new features you're basically admitting that you should have added macros programmatic access to the reader.

> It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names.

Well syntax is at a minimum in Common Lisp. It tends to avoid syntactical short-hand. The most common I know of being QUOTE, BACKQUOTE, UNQUOTE, UNQUOTE-SPLICE, and FUNCTION: ' ` , ,@ and #' respectively.

If you read the preface to the first edition of Structure and Interpretation of Computer Programs I think you will find an enlightening explanation of, Why Lisp?. To paraphrase a brief summary: there are very few ways to form compound expressions and hardly any syntax at all so that the programmer can get to the problem at hand within an hour: the language disappears.

The longer names are chosen stylistically based on the maxim that computer programs are meant for humans to read and only incidentally to be executed by a computer.

Lisps are not, contrary to popular mythology, list-processing languages. It's a symbolic language. The relationship between symbol and data allows the programmer to think primarily about the transformations to data without the abstractions becoming weak.

> Why not switch the parens to something that's a single keystroke?

You could. Common Lisp gives you access to the reader. You can write a more fitting syntax you are more comfortable with.

I've written reader macros to parse assembler instructions for an emulator I wrote in Common Lisp.

> this just seems to be moving things around, not really improving anything

That's my impression too. These sorts of experiments are worth trying from time to time in order to see if something can come from them. Maybe something will come out of this.

But ultimately people bike-shed over "car/cdr" and specialized functions for specific data-types (ie: AREF, GET-HASH, etc). You can write higher-order functions to abstract away sequence access and iteration if you want: people have and there are good libraries for it.

The standard hasn't changed AFAIK because:

1. It'd be expensive and nobody wants to fund another ANSI committee.

2. There haven't been any significant proposals the necessitate revisiting the specification.

People complain about the lack of run-time support for concurrency and IO in the specification. I don't think they realize, coming from other languages, that Common Lisp doesn't need it. The specification defines the language and a minimal ball of mud for doing practical work with it. Things like concurrency, threading, and IO are implementation issues and have been solved by high-quality open-source implementations for quite some time. We even have good libraries that provide a cross-platform layer to things like threading.

Re: CL21: An experimental project redesigning Common Lisp

#65

Post by gjm11 »

philh wrote: post #58
agumonkey wrote: post #43

Earlier quoted context omitted.

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.

fst/rst, although having the difference in the middle also seems aesthetically appealing to me.

Neat, but unfortunately the equivalent of CADR (second item in list: first-of-rest) is then FRST, which I think would just be too easy to misinterpret as meaning "first" when reading or writing code in a hurry.

Re: CL21: An experimental project redesigning Common Lisp

#66

Post by Moyamo »

joesb wrote: post #50

Three things I don't like about Common Lisp. 1. It has CLOS but it doesn't really embrace it in standard library. You have list, vector, hash-table, each with its own iterator function. You have lots of #with-xxx macro. All modern languages utilize the idea of common interface like #iterator or #dispoable. You can clearly see CLOS library and pre-CLOS library in CL. CL needs to eat its own dog food (CLOS) more. 2. It…

I agree with all your points.

One of my main gripes with Common Lisp is its complexity. When I started learning Lisp, I expected to find a beautiful and elegant language, one without a need for syntax. The way C is almost an elegant assembly. Maybe I should have tried Scheme instead.

Common Lisp is anything but elegant. Instead of a regular syntax, you get all these "mini-languages", like the format syntax e.g.

    (format t "~{~a~^, ~}" '(1 2 3))
    ; prints out
    ; 1, 2, 3
This works fine for list, but not for vectors, which is a problem, since I needed vectors often (for random access).

The loop macro is also quite powerful and complicated. e.g.

    (loop :for i :from 1 :to 1000 :collect (* i i))
will create a list of square of 1 to 1000. The loop macro can become really convoluted, not at all simple.

The fact that Common Lisp is a Lisp-2 makes treating functions as first-class as rather awkward. I could never remember when I needed to prepend a lambda with #'.

This article may be of interest http://xahlee.info/comp/Common_Lisp_quotations.html

I found much of the elegance I was expecting in Haskell. But maybe Scheme is a better lisp.

Re: CL21: An experimental project redesigning Common Lisp

#67

Post by elektronjunge »

Immortalin wrote: post #52
mark_l_watson wrote: post #2

This 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…

LLVM isn't a vm like the others, its a generic compiler backend. Languages with LLVM backing generally compile to native.

Re: CL21: An experimental project redesigning Common Lisp

#68

Post by agumonkey »

philh wrote: post #58
agumonkey wrote: post #43

Earlier quoted context omitted.

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.

fst/rst, although having the difference in the middle also seems aesthetically appealing to me.

Good catch.

While writing a toy lisp I looked for other names with structural qualities, actually not names, more symbols since these weren't words.

Things like Oo/oO, xo/ox or _/__.

Re: CL21: An experimental project redesigning Common Lisp

#69

Post by agumonkey »

gjm11 wrote: post #65
philh wrote: post #58

Earlier quoted context omitted.

fst/rst, although having the difference in the middle also seems aesthetically appealing to me.

Neat, but unfortunately the equivalent of CADR (second item in list: first-of-rest) is then FRST, which I think would just be too easy to misinterpret as meaning "first" when reading or writing code in a hurry.

I don't know if cr shortcuts are still used often nowadays (SICP advocates for abstraction layers, accessor functions, CL has destruct-bind, and ml uses pattern matching to dig into data).

Re: CL21: An experimental project redesigning Common Lisp

#70

Post by tempodox »

one-more-minute wrote: post #56
Immortalin wrote: post #52

Earlier quoted context omitted.

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…

Have you met Julia? I don't know if I'd quite call it a functional Fortran, but it's not that far off, either.

Sadly, Julia will not produce stand-alone executables in the foreseeable future. It's nothing more than a bit of native glue between two Python scripts. The main acceptance group doesn't use it for production, only in the lab.
Post reply on HN