On Dec 18, 8:07 pm, Martin Coxall <pseudo.m...@me.com> wrote:
> I had this thought at work, when I should have been working, so please bear 
> with me if it's nonsense.
>
> One of the things that always puts people off of Lisp, as we all know, are 
> the parentheses. Now, many ways have been suggested of doing this in other 
> Lisps, but have never taken off, mainly due to inertia and a fear of 
> sacrificing homoiconicity.
>
> However, I love Clojure, and want to see it really take off. And so I want to 
> see all barriers to that removed. Also, I think the language is young enough 
> that seemingly-but-not-really radical proposals can still be sneaked in.
>
> Let's take this example, since I note that Rich Hickey weighed in in the 
> comments:
>
> http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html
>
> (apply merge-with +
>         (pmap count-lines
>                 (partition-all *batch-size*
>                         (line-seq (reader filename)))))
>
> This little snippet has ten parentheses. And is potentially very unnerving to 
> a non-lisper. Ten parentheses in four lines seems a lot to most programmers.
>
> Rich, in the comments, suggests a pipelined style to make the code more 
> readable:
>
> (->> (line-seq (reader filename))
>   (partition-all *batch-size*)
>   (pmap count-lines)
>   (apply merge-with +))
>
> I accept that this is more readable because it has less nesting. But it now 
> has *12* parentheses, more than the original, potentially just as alarming to 
> the Lispophobes.
>
> My question is this: why can't we introduce a simple and importantly, 
> optional 'off-side rule' (much simpler than Haskell's) that allows the reader 
> to infer many of the parentheses?
>
> A very simple offside rule could turn the original into:
>
> apply merge-with +
>         pmap count-lines
>                 partition-all *batch-size*
>                         line-seq (reader filename)
>
> With a startling two parentheses and Rich's corrected version into:
>
> ->>
>   line-seq (reader filename)
>   partition-all *batch-size*
>   pmap count-lines
>   apply merge-with +
>
> Also with two. That last example in particular looks splendidly readable. 
> Almost... monadic.
>
> The parenthesis inference here is very simple, and could be stated in two 
> sentences:
>
> For each line that is not within a vector, and does not have an opening 
> parenthesis, infer an opening parenthesis at the start of the line. Remember 
> the level of indentation, and infer a closing parenthesis at the end of the 
> line *before* the next line whose indentation is the same as or less than the 
> remembered one.
>
> My question is: why would such a scheme work/not work, and why would/would 
> not it be desirable?
>
> Martin

Whitespace-sensitive S-exprs have indeed already been implemented for
Clojure. The author's github account seems to have been renamed/
deleted, however:

http://209.85.129.132/search?q=cache:-f3Sb3BYidoJ:github.com/onyin/pleajure

For my own toy programs, I have seen little use for significant
whitespace in Clojure so far. Even though I work with Python
professionally and like it's lack of syntactical noise, Clojure's
parentheses (and vector brackets, and map braces) tend to communicate
the programmer's intent more clearly, especially when code becomes as
dense as is possible using Lisps/FP. All of this once the initial
hurdle is overcome, of course. Clojure just looks and feels different
compared to most mainstream languages, different even compared to the
more traditional Lisps.

I guess it's mostly a matter of judging a language by its long-term
merits instead of initial appearance -- just like with so many other
things in life.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to