optimization of list comprehensions

[Mats Cronqvist]

   indeed. i tend to use lists:foldl, lists:map and lists:foreach a lot. i would 
really like to have comprehension syntax for all three of them.

   my suggestion for the foldl-like comprehension is

(x(I,'_') || I <- List, '_' <- Acc0) -> Acc1

   where '_' is the accumulator. it would shadow a previously bound '_'. the 
foreach comprehension

(x(I) || I <- List) -> X

   (where X is x(L) and L is the last element of List) would be a special case 
of this.

    all real language designers should feel free to flame me. it'll be educational.

   mats

Serge Aleynikov wrote:
> I do want to throw a vote for Mats' suggestion on the alternative syntax:
> 
> (I || I <- List) -> ok
> 
> What I also find limiting is that it's not possible to have an 
> accumulator when using list comprehension.  Perhaps something like this 
> could also be considered (unless someone can suggest a better syntax):
> 
> [Acc+1, I || Acc, I <- List](0) -> Acc1
>                              ^
>                              |
>                        Initial Acc's value
> Serge
> 
> Robert Virding wrote:
> 
>> I have been thinking about this a bit and I wonder if the constructing 
>> of the return list really causes any problems. Space-wise it will only 
>> be as large as the size of the input list, so I wouldn't worry.
>>
>> Robert
>>
>> Ulf Wiger (AL/EAB) skrev:
>>
>>> I've seen many examples of how people use
>>> list comprehensions as a form of beautified
>>> lists:foreach() - that is, they don't care
>>> about the return value of the comprehension.
>>>
>>> I hesitate to say that it's bad practice,
>>> even though one will build a potentially
>>> large list unnecessarily, since it's actually looks a lot nicer than 
>>> using lists:foreach().
>>>
>>> Question: would it be in some way hideous
>>> to introduce an optimization where such
>>> list comprehensions do everything except
>>> actually build the list? Then they could
>>> execute in constant space.
>>>
>>> /Ulf W
>>>
>>
>