[Haskell-cafe] Proposal: Non-recursive let
ekmett at gmail.com
Wed Jul 17 21:46:46 CEST 2013
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
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
> -- | 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,
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe