optimization of list comprehensions

[Mats Cronqvist]

Richard A. O'Keefe wrote:
> I wrote:
> 	> I am not at all happy about (Expr || Pat <- List) because
> 	> (A) it looks like a syntax error; it's quite likely to be 'corrected'
> 	>     to use square brackets
> 
> Mats Cronqvist <mats.cronqvist@REDACTED> replied:
> 	   "looks like a syntax error"?  doesn't that depend on what the
> 	syntax is?
> 
> No.  It depends on what people *THINK* it is.  The term was "looks like",
> not "is".
> 
> 	"corrected" by whom?
> 
> People, what else?  Maintenance programmers often fix things that aren't
> really broken (sometimes until it _is_ broken; the KMP pattern matcher
> is a good example.)  They are especially likely to fix things that LOOK
> broken.

   so the maintenance programmers are unable to learn new syntax? given that we 
train our maintenance programmers from scratch, i don't see that as an issue.

> 	anyway, the use of '(' and ')' is incidental, the point is 
> 	to not use '[' and ']' (to make it clear that we're not
> 	returning a list).
> 	
> But with everything else so very strongly resembling the syntax for
> a list comprehension, the use of round parentheses is NOT enough to
> make it CLEAR that we are not returning a list.
> 
> If you really want to be clear, make it
> 
>     (do Expr for Pat <- List)
> 
> with the trivial case of iterating over no lists being
> 
>     (do Expr)
> 
> 	   surely using the [] notation is even worse in that regard.
> 	
> A headache may not be as bad as a toothache; but if I have a toothache
> it doesn't help me much to give me a headache as well.

   true enough. unfortunately, the analogy doesn't help me much since i'm not 
sure if the round parantheses are affecting your head or your teeth.

> 	> As for combining accumulation with list comprehension,
> 	> one can already write
> 	>     lists:foldl(fun (X,Y) -> X+Y end, 0, 
> 	> 	        [some list comprehension goes here])
> 	> which isn't *that* bad.  
> 	
> 	   i think it is that bad :>
> 
> 	   here's the thing.  the list comprehensions were introduced
> 	for no good reason, in that they added nothing that you could
> 	not already do.  but they make my life easier because they offer
> 	a much more succinct notation (especially since i have to look
> 	at other people's code a lot).
> 
> I think you just said that making your life easier is not a good reason.

   no, but i guess i was unclear. i'll try to restate.
   list comprehensions didn't add any functionality, they just added 
succinctness. and that turned out to be A Good Thing. therefore, dismissing 
other features that add succinctness but not functionality is silly.

> One really important thing here is that there was *precedent* for
> list comprehensions.  By the time Erlang got them, list comprehension
> was a well established notation (up to choice of punctuation marks)
> which had proven itself in several different languages.  (Even Prolog
> all-solutions" operations are related, and, by the way, always construct
> lists.)
> 
> If you except Interlisp and Common Lisp, there *isn't* any precedent
> for a comprhenion-cum-fold.  So the risk of doing it badly is high;
> it's not just a matter of adopting an already-existing notation.  And
> the evidence so far bears this out:  the actual concrete proposals in
> this thread are quite astonishingly BAD.

   yes, it truly is astonishing, the amount of complete and utter drivel one has 
to wade through. really makes you long for the good old days before arpanet.
   i feel slightly encouraged that you have to make an exception of Common Lisp 
though. and perhaps the OTP peoply would be capable of coming up with reasonable 
notation (even if i'm clearly not).

[...]