This happened because I copied the surrounding style blindly. I fucked up. state f = get >>= \s -> case f s of (a, s) -> do put s return a
would not have the problem and would have given a warning about name shadowing. I for one am somewhat neutral on the *adding* a non-recursive let to the language, but I personally think case serves this purpose, and folks have shown above that you can get it from a simple x & f = f x combinator. But I do not think that let should be non-recursive by default. I commonly give a soup of possibly-recursive definitions using let or where and the story for how to write such functions in a language where let is non-recursive is much more painful. -Edward On Wed, Jul 17, 2013 at 12:23 PM, Andreas Abel <andreas.a...@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@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.a...@ifi.lmu.de > http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/> > > ______________________________**_________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe