List Comprehensions in Eight Lines of Clojure (opens in new tab)

Clojure's `for` is ~80 lines of code, and isn't particularly accessible. My goal here wasn't to reinvent the wheel, but to give an example of a not-totally-trivial macro that does something neat. :)

(Clojure is simply my lisp of choice. This could be just as easily implemented in elisp, which does not have this built in.)

[edit] For those interested, here's an elisp version: https://gist.github.com/4430934

Yes, exactly. I am confused. Why use Clojure for the example, when Clojure already has this built in? I don't know all of the Lisp's, but if one of them does not have this, it would make sense to offer the example in that language.

Having said that, there is probably some educational value in writing out what a special form would look like if it was not a special form, so in that regard, yes, this is interesting to look at.

`for` is a macro, not a special form. Special forms are these: http://clojure.org/special_forms

Without monads?)

Very cool! I'm not completely sure how it would support comprehensions over more than one list, though (as in the permutations example).

The point of a list comprehension is often that it can work with multiple lists. This can't do that, can it?

Ditto for Perl with modules like List::Maker and List::Gen.

However like the Ruby example this only works on a single list. Which reminds me that I keep meaning to write a port of CL loop in Perl using Devel::Declare.

ref: https://metacpan.org/module/List::Maker | https://metacpan.org/module/List::Gen | https://metacpan.org/module/Devel::Declare

> This is very telling example of how differently Java people think.

Notice how the blog didn't even mention Java once and is talking about Clojure and defmacro, still you managed to imagine the article, an argument and respond to it. What more, your response is on the lines of "The earth goes around the sun" -> "Hah. No".

> First of all - ''this'' is NOT list comprehensions

This is list comprehension as in the accepted definition of list comprehension.

> Lisp has list comprehension, the sub-set of features that makes macros possible. Quote, back-quote, comma and grouping with parenthesis are parts of Lisp syntax to do it.

List comprehension doesn't mean whatever you want it to mean.

http://en.wikipedia.org/wiki/List_comprehension#Common_Lisp

> Look at it carefully. This is the how confusion looks like.

Look at this comment carefully. If you ever wondered how empty vessels make most noise, this is how it looks like. Without pointing out anything in the article which is wrong or can be improved, or without even giving out unrelated examples(that would have been something), this comment has shit all over it over some delusional sense of lisp programmers superior to Java programmers. It might have been a bit acceptable if the comment would have posted a clever lisp solution, or the blog would have had anything to do with Java at all.

> Thinking in terms of classes and methods prompts them to create artificial, unnecessary complications.

And again, imagine arguments and respond to them. Where on earth TFA mentioned classes and methods?

Also, this fucking hippy culture of "classes suck; functional programming rockz; lolz" need to die. What makes it more irritating is 99.999% of the times, the person singing the praises of lisp, functional programming et al. and trashing Java(there is a very high correlation) is a fucking moron and can't code to save his life, in lisp or any other language. Do a 100,000 lines project in Haskell, come back and then tell me how classes suck and this functional programming project of yours is so much better. Even then, that will be just personal anecdote, but currently, it's just incoherent, incompetent rambling.

I don't think you understand what was claimed in the article. 'List comprehension' is the name of a specific syntactic construct. List comprehensions describe straightforward transformations of other lists in convenient notation. http://en.wikipedia.org/wiki/List_comprehension

They're syntactic sugar for map and filter. Consider this python code:

    [x**2 for x in range(100) if x % 2 == 1]

This is a list comprehension. It's equivalent (in 2.x) to the Python

    map(lambda x: x**2, filter(lambda x: x%2 == 1, range(100)))

(or in Clojure,

    (map #(* % %) (filter #(= 1 (mod % 2)) (range 100)))

(seems like cheating to use the odd? function))

...so, equivalent to map and filter, just with better syntax.

Caveat: in 3.x, python's map and filter return generators, so the equivalent comprehension would be a generator comprehension instead--just the same thing as above but wrapped in parens and not square brackets--which would also return a generator.

"We don't address this in the post, but adding :while conditions is quite a fun challenge."

Eurgh, I hate the common Clojure habit (you see it in for, doseq, etc. loops, and in domonad, which is annoying in other ways) of abusing binding vectors to add in extra stuff that doesn't, in itself, have anything to do with binding names to values.

If you use a very slightly modified version of the macro defined at [1] (modified to use algo.monads), you can do list comprehensions like this:

     > (monads/with-monad
             monads/sequence-m
             (mdo x <- [1 2 3]
                  y <- [3 4 5]
                  let added = (+ x y)
                  (monads/m-result [x y added])))
     ([1 3 4] [1 4 5] [1 5 6] [2 3 5] [2 4 6] [2 5 7] [3 3 6] [3 4 7] [3 5 8])

The "let added = (+ x y)" is an unnecessary flourish: it would have worked just as well to wrap what followed in (let [added (+ x y)] ...). Likewise (as against domonad), you can just use regular old if; no need for :if.

1: https://bitbucket.org/kenko/macroparser/src/7a492ef941db38db...

Haha, this is really fun :)

I'm looking forward to exploring your blog.

yes and no. Yes, because the example is a novel language feature in other languages that would be very difficult to implement. No, because these sorts of things are easy only when code is data, like lists, which is a design property of lisps, but not really captured within 'list processing'. I think perhaps there could exist a language that says it's good at lists and data without the macro system that makes this possible.