4 ms·

Don't call it Lisp. Lisp begins with something like this: (defmacro when (test &body forms) `(cond (,test nil ,@forms))) Without using underlying lis

Don't call it Lisp. Lisp begins with something like this: (defmacro when (test &body forms) `(cond (,test nil ,@forms))) Without using underlying list structure, environments, lexical scoping and reader function it is just a lisp-like syntax. Lisp without lists at its core is nothing but another clumsy language. Look at Clojure - what a mess.

guard-of-terra 14y ago
What's the problem with Clojure?: (defmacro when "Evaluates test. If logical true, evaluates body in an implicit do." {:added "1.0"} [test & body] (list 'if test (cons 'do body))) Moreover, what's the problem with μLithp? l.eval [:label, :second, [:quote, [:lambda, [:x], [:car, [:cdr, :x]]]]] l.eval [:second, [:quote, [1, 2, 3]]] Seems list-y enough for me. I have a feeling that you didn't actually read the article.
- dschiptsov 14y ago
  There isn't any problem with this Clojure macro. If you would like to see problems with Clojure, take a look at keep function in core.clj. There is a classic function: (define (filter fn l) (cond ((null? l) '()) ((fn (car l)) (cons (car l) (filter fn (cdr l)))) (else (filter fn (cdr l))))) The point is that stuffing more data-structures into a lisp ruins it. Somehow switching to the prefix notation and adding parenthesis doesn't transform Java to Lisp. For the second piece of code - are't semicolons and comas somehow redundant? Moreover, what is the point of writing something this way?
  - vmind 14y ago
    Not sure what the objection to the keep function is, other than maybe the performance optimisations that chunked sequences allow. Taking away the chunked consideration gives something like: (let [x (f (first s))] (if (nil? x) (keep f (rest s)) (cons x (keep f (rest s))))) Which looks almost identical (with differences, as you seem to be giving filter rather than keep, which are different functions). The library function COULD be defined like this, it just wouldn't be as fast.
    - dschiptsov 14y ago
      Taking away the chunked consideration...
  - deleted 14y ago
    [deleted]
  - chongli 14y ago
    >The point is that stuffing more data-structures into a lisp ruins it. Could you please support this assertion?

guard-of-terra 14y ago

What's the problem with Clojure?: (defmacro when "Evaluates test. If logical true, evaluates body in an implicit do." {:added "1.0"} [test & body] (list 'if test (cons 'do body))) Moreover, what's the problem with μLithp? l.eval [:label, :second, [:quote, [:lambda, [:x], [:car, [:cdr, :x]]]]] l.eval [:second, [:quote, [1, 2, 3]]] Seems list-y enough for me. I have a feeling that you didn't actually read the article.

dschiptsov 14y ago
There isn't any problem with this Clojure macro. If you would like to see problems with Clojure, take a look at keep function in core.clj. There is a classic function: (define (filter fn l) (cond ((null? l) '()) ((fn (car l)) (cons (car l) (filter fn (cdr l)))) (else (filter fn (cdr l))))) The point is that stuffing more data-structures into a lisp ruins it. Somehow switching to the prefix notation and adding parenthesis doesn't transform Java to Lisp. For the second piece of code - are't semicolons and comas somehow redundant? Moreover, what is the point of writing something this way?
- vmind 14y ago
  Not sure what the objection to the keep function is, other than maybe the performance optimisations that chunked sequences allow. Taking away the chunked consideration gives something like: (let [x (f (first s))] (if (nil? x) (keep f (rest s)) (cons x (keep f (rest s))))) Which looks almost identical (with differences, as you seem to be giving filter rather than keep, which are different functions). The library function COULD be defined like this, it just wouldn't be as fast.
  - dschiptsov 14y ago
    Taking away the chunked consideration...
- deleted 14y ago
  [deleted]
- chongli 14y ago
  >The point is that stuffing more data-structures into a lisp ruins it. Could you please support this assertion?