optimization of list comprehensions
Fri Mar 3 10:53:19 CET 2006
Richard A. O'Keefe 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
"looks like a syntax error"? doesn't that depend on what the syntax is?
"corrected" by whom? 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).
> (B) it reduces the parser's ability to diagnose syntax errors
> (C) nothing about it visually suggests the most important piece of
> information, which is that the expression is executed for side
> effects, not for its value.
surely using the  notation is even worse in that regard.
> The idea of explicitly writing "_ = [Expr || Pat <- List]" has none
> of those defects. The only compiler change that's called for is to
> emit a warning when the value of a list comprehension *isn't* used in
> some way (including _= as a use).
yes, this would be a nice addition.
> 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 want the same improvement for fold-like
> Any more direct syntax (such as something
> based on the Lisp 'do' construct, for example) would have to involve
> some way of presenting two bindings for the same names in the same
> construct (as 'do' does), which is not a very Erlangish thing to do.
being an old FORTRAN programmer i had no idea what the Lisp 'do' construct
was. it is indeed (as far as i can tell) exactly what i want. thanks for the
More information about the erlang-questions