Re: Accumulator syntax breaks precedence

On Feb 1, 2011, at 4:36, Thomas Leonard wrote:

> I could never get the hang of the accumulator syntax. Is there any
> chance of something like Python-style list comprehensions and  
> generator
> expressions?


Accum is much like Python comprehensions, actually -- it has the same  
property of embedding control constructs as special syntax -- the  
complication is that accum generalizes to accumulating maps, sets,  
numbers, and other objects. The "_ <op> ..." notation is used to  
capture that custom accumulation, whereas in Python it is implicit in  
the choice of [] or ().

If we have a decent generator/series/stream design which we're willing  
to bake into the language, then we could just have generator  
expressions (and utilities to accumulate the results into collections  
or numbers) and it would resolve the problems with accum.

However: Python's generator syntax is elegant, but E prefers to avoid  
constructs where defining occurrences of variables appear after their  
uses. So that leaves us with, to imitate your examples,

(Python) sum(2 * x for x in items)
(E)      sum(gen for x in items { 2 * x })

(Supposing we use 'gen' where we currently use 'accum'.)

But doing this is a bit odd as 'for' usually ignores the value of its  
block; accum at least has special syntax to mark the inside of an  
accumulation. Furthermore, a generator has inversion of control flow,  
which is unexpected for 'for'.

Those particular arguments, combined with the claim I made before that  
'accum if' and 'accum while' are rarely useful, suggest that the  
syntax should only do 'for'-equivalents, and not look like a 'for' loop.

... I just realized a further complication: Iteration in E, as  
defined, can't produce a generator, because it is internal iteration  
(for x in y {f(x)} => y.iterate(fn _,x {f(x)}), roughly) -- control  
doesn't return to the caller of iterate until the complete collection  
is iterated.

I'm intending to fix this by redefining iteration in terms of streams,  
but I don't quite know what the result will look like yet. I'll try to  
do that with attention to a replacement for accum.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>