[Haskell-cafe] Proposal: Non-recursive let

Andreas Abel andreas.abel at ifi.lmu.de
Thu Jul 18 09:57:40 CEST 2013


On 17.07.13 9:46 PM, Edward Kmett wrote:
> FWIW, I maintain, according to wc and sloccount, 220841 lines worth of
> Haskell code at present.

Thanks, this is great service to our community.  And you produce 
excellent quality!

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




More information about the Haskell-Cafe mailing list