[erlang-questions] Code generation (was NOOB)

[Richard A. O'Keefe]

Jay Nelson <jay@REDACTED> wrote:
	The fact that list comprehensions always construct a list is an
	artifact of their genesis.  I agree their syntax intentionally
	suggests you are creating a list, but I still prefer the
	readability even only for side effects.  Using them and reading
	them clicks my mind into erlang mode.

I once experimented with a Haskell-like syntax for Erlang.
To my pleased surprise "Herlang" code was usefully shorter than Erlang.
One of the things I did was to generalise list comprehension syntax:

    [e1, e2, ... for p1 in l1 | g1 ... for pk in lk | gk]
	-- list comprehension

    {e1, e2, ... for p1 in l1 | g1 ...
	-- tuple comprehension

    (&& e1 for p1 in l1 | g1 ...)
	-- bounded universal quantification

    (|| e1 for p1 in l1 | g1 ...)
	-- bounded existential quantification

    (,, e1, e2, ... for p1 in l1 | g1 ...)
	-- "for loop" done for side effects
	
I would have added syntax for max, min, and sum, but they weren't common
enough in the Erlang code I was rewriting to bother.  Note that Haskell
doesn't need special syntax for 'any' (||...) and 'all' (&&...) because
it is lazy; a strict language does need special syntax for these rather
useful cases.

I am *not* recommending this particular syntax, just noting that
"generators with guards" CAN be liberated from "constructing a list"
and that doing so would be even clearer than constructing a list which
is "obviously" thrown away.

I also note that precisely this liberation is part of the
(let p1 = i1 then s1, ....	[More Erlangish:   let p1 = i1 then s1, ...
 for <generators>				   for <generators>
 in <result>					   in  <result>
)						   end]
syntax that I *have* proposed in this mailing list.  As that was invented
as a generalisation of folding, it doesn't handle 'foreach' particularly
well.  The point is that we *could* have generators in syntax other than
list comprehension syntax, and it may be worth exploring _which_ other
syntax would be useful.