4 ms·

It might be a nice language but not an especially nice Lisp. Lots of stuff from Lisp is missing: interpreter and compiler integrated, self hosting compiler writ

by lispm 9y ago

It might be a nice language but not an especially nice Lisp. Lots of stuff from Lisp is missing: interpreter and compiler integrated, self hosting compiler written in Lisp, condition system with interactive error handling, nice object-system like CLOS, simpler numeric tower, good error messages, Lisp-like stack traces, image-based development with fast startup times, Tail Call Optimization, continuations, ... plus it has some strange design decisions with basic list data structures. It's 'Lisp'-like where the basic primitive list processing has been replaced with a different higher-level data structure (persistent sequences) built on top of an alien infrastructure which leaks through everywhere and which was not developed for interactive programming (the JVM)... That was one of its original design decisions: being hosted on top of the JVM.

TeMPOraL 9y ago
> It's 'Lisp'-like built on top of an alien infrastructure which leaks through everywhere... Given it's Lisp (CL in particular) that's "built with alien technology"™, I'd say Clojure is built on top of terran architecture, with the usual human stuff leaking everewyhere... ;).
- aerique 9y ago
  Would Common Lisp be Zerg or Protoss technology?
  - TeMPOraL 9y ago
    Xel'naga.
dang 9y ago
> some strange design decisions with basic list data structures What are those?
- lispm 9y ago
  Hopefully a Clojure user will correct me, but something like (1 2 3) has a single printed representation for slightly different data structures. You can construct something which prints as (1 2 3) and when you read it, then it is something else. user=> (list 1 2 3) (1 2 3) user=> (list? (list 1 2 3)) true user=> '(1 2 3) (1 2 3) user=> (list? '(1 2 3)) true user=> (cons 1 '(2 3)) (1 2 3) user=> (list? (cons 1 '(2 3))) false It might not be a big deal, but from a language design view I would expect the single most important external data structure representation in Lisp - a list - is not overloaded with different data structures, where basic operators give different results. I personally would also think that in Lisp the predicate list? is fundamental and returns true for everything which looks printed like a list. Common Lisp has a related problem for arrays: there are some attributes of arrays which have no printed representation. One will read an array back, but it might lack some features - like not having a fill-pointer. But atleast ARRAYP will still return true. This seq/list thing might not be a big deal in practice, but it's another design wart. The language has in several places names, which are fundamental in Lisp and which mean something totally different now. Like 'atom'. Since the concept of a Lisp atom no longer applies - remember we have seqs, not linked conses - the name was reused to mean something different. atom used to mean (not (consp thing)) now it is something else.
  - dang 9y ago
    Thanks! Super interesting. Of course the meaning of (not (consp thing)) for atom is classical, but don't you think it's a bit weird? It always struck me that way. In a language where lists were the only composite data structure (i.e. not being a cons means being a number or a string or a symbol), it made sense, but that meaning degrades once you have vectors and hashtables. Those are no more deserving of the name 'atom' than lists are. Indeed if one indulges in the oxymoron of treating atomicity as a spectrum, vectors feel more atomic to me than lists while hashtables feel less atomic.
    - kbp 9y ago
      Older Lisps didn't tend to have strings as a separate datatype, they just used symbols and there was a function EXPLODE (and similar) for turning a symbol into a list of one-character symbols (or fixnums), and a corresponding IMPLODE (and similar) for combining them again, and that's how string processing was done. Vectors and hashes predate "real" strings in Lisp as far as I'm aware.

by lispm 9y ago

TeMPOraL 9y ago

> It's 'Lisp'-like built on top of an alien infrastructure which leaks through everywhere... Given it's Lisp (CL in particular) that's "built with alien technology"™, I'd say Clojure is built on top of terran architecture, with the usual human stuff leaking everewyhere... ;).

aerique 9y ago
Would Common Lisp be Zerg or Protoss technology?
- TeMPOraL 9y ago
  Xel'naga.

dang 9y ago

> some strange design decisions with basic list data structures What are those?

lispm 9y ago
Hopefully a Clojure user will correct me, but something like (1 2 3) has a single printed representation for slightly different data structures. You can construct something which prints as (1 2 3) and when you read it, then it is something else. user=> (list 1 2 3) (1 2 3) user=> (list? (list 1 2 3)) true user=> '(1 2 3) (1 2 3) user=> (list? '(1 2 3)) true user=> (cons 1 '(2 3)) (1 2 3) user=> (list? (cons 1 '(2 3))) false It might not be a big deal, but from a language design view I would expect the single most important external data structure representation in Lisp - a list - is not overloaded with different data structures, where basic operators give different results. I personally would also think that in Lisp the predicate list? is fundamental and returns true for everything which looks printed like a list. Common Lisp has a related problem for arrays: there are some attributes of arrays which have no printed representation. One will read an array back, but it might lack some features - like not having a fill-pointer. But atleast ARRAYP will still return true. This seq/list thing might not be a big deal in practice, but it's another design wart. The language has in several places names, which are fundamental in Lisp and which mean something totally different now. Like 'atom'. Since the concept of a Lisp atom no longer applies - remember we have seqs, not linked conses - the name was reused to mean something different. atom used to mean (not (consp thing)) now it is something else.
- dang 9y ago
  Thanks! Super interesting. Of course the meaning of (not (consp thing)) for atom is classical, but don't you think it's a bit weird? It always struck me that way. In a language where lists were the only composite data structure (i.e. not being a cons means being a number or a string or a symbol), it made sense, but that meaning degrades once you have vectors and hashtables. Those are no more deserving of the name 'atom' than lists are. Indeed if one indulges in the oxymoron of treating atomicity as a spectrum, vectors feel more atomic to me than lists while hashtables feel less atomic.
  - kbp 9y ago
    Older Lisps didn't tend to have strings as a separate datatype, they just used symbols and there was a function EXPLODE (and similar) for turning a symbol into a list of one-character symbols (or fixnums), and a corresponding IMPLODE (and similar) for combining them again, and that's how string processing was done. Vectors and hashes predate "real" strings in Lisp as far as I'm aware.