optimization of list comprehensions

[Richard A. O'Keefe]

Mats Cronqvist <mats.cronqvist@REDACTED> wrote:
	   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.
	
Has anyone actually made such a dismissal?
I certainly haven't.
After all, one of the arguments for Erlang itself is its conciseness
compared with Java (although I must say it is very hard for any programming
language not to be more concise than Java).

The requirements for any new notation are
 - that it be readable
   (so using strange characters is unwise, Smalltalk's use of "^"
    (historically an up-arrow) for "return" pushes the limits),
    and using unpronouncable keywords is folly (keywords written
    backwards didn't succeed in the marketplace of ideas, and
    apparently even Microsoft have given up on Hungarian notation)

 - that it not depend on fine distinctions of character shapes
   (the use of [...] for lists and {...} for tuples is already
    pushing the limits a bit; the different senses given to
    "," and ";" in Prolog certainly proved very confusing even
    for people capable of writing Prolog compilers)

 - that it not tend to mislead people into believing that it means
   something else (thus Fortran's use of / for integer division,
   followed by C and of course Java, was a Bad Idea)

 - that it have sufficiently high payoff
   (there must be many occasions to use it, and the effort saved by
    using it must be great enough).  Since programs are *read* more
    often than they are *written*, the effort that needs to be saved
    is the effort of *reading* and understanding the notation, not
    the effort of *writing*.

Now we actually have three things we are discussing here:

 - list comprehensions (and why don't we have tuple comprehensions?
   Clean has them, and I use them a lot when writing Clean)

   We have them in Erlang, because of Mnemonsyne.

 - list walking for side effect (not needed in Haskell because there
   aren't any side effects)

   We can get this effect simply by sticking "_ =" in front of a
   list comprehension (or any other variable name that is clearly
   not intended to be used again) and having a very slightly smarter
   compiler.  I _hope_ it would not be very useful.

 - list folding (and again, tuple folding would be nice too)
   Presumably one of the reasons that Haskell doesn't have this is
   that Haskell has at least four different versions of fold

   This one certainly would be useful; the OTP sources could use some
   kind of fold at least 400 times, and foldl at least 300 times.

   I think it would be advisable to check several hundred potential
   uses of the notation before designing a concrete syntax.