[Haskell-cafe] Re: Re: Lambda-case / lambda-if
Jonathan Geddes
geddes.jonathan at gmail.com
Fri Oct 8 12:34:13 EDT 2010
I can honestly say that I haven't felt much pain from the status quo
regarding this. Most of the time my code is structured so that case
statements don't appear in do blocks. When they do, I don't see it as a big
issue. The special case for operator - is a bigger wart on haskell syntax
than this, imo.
I would vote in favor of keeping the language simple. I do like the idea of
generalizing lambda functions to include multiple cases, however.
On the other hand, I almost never use lambdas now since named functions
yield better "self-documenting" code.
--jonathan
On Oct 8, 2010 8:09 AM, "Peter Wortmann" <scpmw at leeds.ac.uk> wrote:
On Fri, 2010-10-08 at 01:13 +0300, Lauri Alanko wrote:
> Your "general" rule doesn't subsume your ...
Yes, that's what I meant. Thanks for describing it properly.
On Fri, 2010-10-08 at 05:41 -0700, Nicolas Pouillard wrote:
> Imagine find this code:
>
> do s1
> ...
This is roughly what I meant with "abused": Where "C" is very complex,
it might become non-obvious where exactly the monad actions are supposed
to happen. Hence such traps when refactoring.
Also of note: Just moving sub-expressions around isn't something that is
guaranteed to be save. Introducing new names and using them in "s2"
would be problematic, for example:
do map (\x -> (<- putStrLn x)) ["a", "b"]
Obviously can't be made to work. You might have to check for this - or
maybe even disallow the shorthand inside lamdbas and lets. Might be less
satisfying to have such special cases, but it is still a good bit more
general than what is available right now.
Greetings,
Peter Wortmann
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20101008/fe8e35b9/attachment.html
More information about the Haskell-Cafe
mailing list