[Haskell-cafe] list comprehension with multiple generator|targets

[Donn Cave]

quoth Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
...
> Also I wonder if laziness saves us here: in the original program we
> effectively do map and filter at the same time. If we were to take
> (catMaybes . map f) with strict evaluation then we'd be traversing
> twice: once to map and once to catMaybes… Just something to think about,
> I think performance would be no worse anyway, at least not by much.

Might be right, I really have little idea what's going on underneath
there - I'd have guessed that lazy or not, the two functions are doing
all the work of traversing their separate lists even if at any conceptual
moment those lists are nothing but a head and a tail.

The rationale is mostly about a cleaner presentation.  I was thinking
of this problem a few weeks back when we were talking about C programmers
learning Haskell.  I'd guess they'd find a certain lack of elegance in
the Maybe strategy, compared to what would be a pretty simple and direct
problem in C, like "for (i = j = 0; i < n; ++i) if (toChar(vx[i], &cx[j]) ++j;"
The recursive function I wrote for reference is my least favorite solution,
less clear and more prone to stupid coding errors.  If my list comprehension
idea had been valid, I think it would have been a very concise presentation.

>> ... in this case I don't think we're desperate enough to use a
>> nonstandard extension.
> 
> I wouldn't worry about using a ‘non-standard’ extension: you're probably
> not going to stick to H98 or H2010 in non-trivial programs either way.
> LambaCase is just a trivially expandable sugar anyway, modulo clean
> identifier name.

I do make frequent use of ForeignFunctionInterface, but perhaps that's the
exception that proves the rule inasmuch as it has little to do with the
language per se.  I'm happy that I don't have to deal with programs that
couldn't have been written without extensions.

	Donn