optimization of list comprehensions

[Richard A. O'Keefe]

!valof 3300 - 2907
I wrote:
	> The pattern illustrated for "fun", if it is to be taken seriously as a
	> grep-style pattern, is guaranteed to miss many of the funs in the OTP
	> sources.

Predictably, Mats Cronqvist <mats.cronqvist@REDACTED>
challenged this:
	"many"? enough to affect the result significantly? example please.
	
m2h -ik -lerl /tmp/ERL | grep -w "fun" | wc -l		=> 3300
fgrep "fun("  /tmp/ERL                 | wc -l		=> 2907

/tmp/ERL is a copy of the R9something OTP sources with comment stripped out.
The "fun(" pattern misses 393 occurrences of the "fun" keyword,
which is nearly 12% of the total.

To me, nearly 400 occurrences may fairly be called "many",
and a 12% error is "significant".  Others may make other judgements.

	> The language has changed.  What *was* 'perfectly fine' Erlang isn't any
	> more.  It's perfectly fine in that it still works, but new code should
	> not be written that way.
	
	   well, i guess i'm a bit more flexible than you in that
	regard.  i think it's ok for people to write C for C++
	compilers, FORTRAN77 for Fortran90 compilers, etc, as long as
	the code works and is readable.
	   of course it would be much *better* if they didn't.
	
It is "perfectly fine" to do something but it would be "much *better*"
if they didn't?  To me that's a contradiction.

By the way, the C++ standard has *PAGES* (I mean *LOTS* of pages) of
incompatibilities between C and C++.  If I want to use C code as part
of a C++ system, I compile it with a C compiler, because a C++ compiler
*must* interpret it in subtly different (and therefore subtly buggy) ways.
Anybody writing C for C++ compilers is not just asking for trouble but
screaming for it like a Siamese cat on heat.

	> In fact, given that we are talking about source code that has been
	> around for a while and not fixed when it wasn't broken, I draw the
	> opposite conclusion to Mats from his own figures.
	
	   this was my conclusion; "one can write well working Erlang code while rarely, 
	if ever, using funs". quite a feat to draw the opposite conclusion from my figures.

No, the conclusion I'm talking about was the one claiming that "industrial"
programmers cannot or will not use funs.  Your evidence shows, on the
contrary, that they can and will once funs are there, reliable, efficient,
and explained to them.

	>     Hypothesis:
	>         The proportion of 'funs' (and list comprehensions) in files
	>         is increasing with time, so that 'industrial programmers'
	>         *are* taking up the new features, they just aren't rewriting
	>         old code for the fun of it.
	
	   this is probably true. of course, it's a non sequitur (or perhaps even a 
	straw man argument?). noone has claimed the opposite, and  no figures that i'm 
	aware of says anything about trends over time.
	
But you *did* claim that "industrial" programmers were staying away from
funs; that's what the whole thread is about!