Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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?


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.


Taking away the chunked consideration...


>The point is that stuffing more data-structures into a lisp ruins it.

Could you please support this assertion?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: