[Haskell-cafe] Proposal: Non-recursive let
andreas.abel at ifi.lmu.de
Wed Jul 17 18:23:31 CEST 2013
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
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
More information about the Haskell-Cafe