[Haskell-cafe] Proposal: Non-recursive let

[Andreas Abel]

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

     -- | 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
>


-- 
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/