[Haskell-cafe] Proposal: Non-recursive let

[Edward Kmett]

FWIW, I maintain, according to wc and sloccount, 220841 lines worth of
Haskell code at present.

I have been bitten this error one time, so it affects me .000045% of the
time and that was only because it was in the only package I was not using
-Wall on.

-Edward

On Wed, Jul 17, 2013 at 12:23 PM, Andreas Abel <andreas.abel at ifi.lmu.de>wrote:

> Here, again, is your ACTUAL CODE, commented, deployed, looping, and maybe
> linked into your projects, if you are not careless about the cabal
> constraints:
>
> http://hackage.haskell.org/**packages/archive/mtl/2.1/doc/**
> html/src/Control-Monad-State-**Class.html#state<http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#state>
>
>     -- | Embed a simple state action into the monad.
>     state :: (s -> (a, s)) -> m a
>     state f = do
>       s <- get
>       let ~(a, s) = f s
>       put s
>       return a
>
> Have fun with it,
> Andreas
>
>
> On 17.07.2013 02:20, Richard A. O'Keefe 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<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>>
>>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Theoretical Computer Science, University of Munich
> Oettingenstr. 67, D-80538 Munich, GERMANY
>
> andreas.abel at ifi.lmu.de
> http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
>
> ______________________________**_________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130717/f3425d7a/attachment.htm>