[Haskell-cafe] Proposal: Non-recursive let

Markus Läll markus.l2ll at gmail.com
Wed Jul 17 11:14:08 CEST 2013

For what it's worth, I think a non-recursive in the language would
just bring more confusion, in forums, IRC and whereever. The benefits
don't seem important at all, and the same effect can be achieved
through other means.

On Wed, Jul 17, 2013 at 2:20 AM, Richard A. O'Keefe <ok at cs.otago.ac.nz> wrote:
> Brian Marick sent me a couple of his stickers.
> The one I have on my door reads "to be less wrong than yesterday".
> The other one I keep free to bring out and wave around:
>         "An example would be handy about now."
> All of the arguing to and fro -- including mine! -- about
> non-recursive let has been just so much hot air.  I could
> go on about how the distinction between 'val' and 'val rec'
> in ML was one of the things I came to dislike intensely,
> and how Haskell's single coherent approach is one of the
> things that attracted me to Haskell.
> But why should anyone else care?
> When presented with a difficulty, it is very common for some
> functional language users to propose adding just one more
> feature from some other language, commonly an imperative one
> (which ML, Caml, and F# arguably are).  Typically this is
> something that _would_ solve the immediate problem but would
> create worse problems elsewhere, and there is some other
> solution, either one already available in the language, or a
> better one that would solve additional problems or cause
> fewer ones.
> The best help for any discussion is A CONCRETE EXAMPLE OF
> REAL CODE.  Not little sketches hacked up for the purpose
> of discussion, but ACTUAL CODE.  The person who initially
> proposes a problem may think some details are not relevant,
> whereas someone else may see them as the key to the solution.
> For example, looking at some code in another mostly-
> functional language, which had been presented as reason why
> we needed a new construct, I rewrote it in less than half
> the number of lines using existing constructors, using only
> existing features.
> Without seeing THE ACTUAL CODE that prompted this thread,
> it is impossible to tell whether that might be the case here.
> In this specific case, we are seeing state being threaded
> through a bunch of updates, and IN THE ABSENCE OF THE ACTUAL
> CODE, it seems to me that monad notation is the most
> intention-revealing notation available for the purpose in
> Haskell, and if Haskell did have non-recursive let it would
> STILL be best to write such code using a state monad so that
> human beings reading the Haskell code would have some idea
> of what was happening, because that's how state changes are
> supposed to be expressed in Haskell, and anything else
> counts as obfuscation.
> But THE ACTUAL CODE might show that this case was different
> in some important way.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

Markus Läll

More information about the Haskell-Cafe mailing list