Re: [Haskell-cafe] Proposal: Non-recursive let

2013-08-02 Thread Andreas Abel
On 26.07.13 6:44 PM, Andreas Abel wrote: headers0 - M.fromList $ do forM fields_header $ \ (n, fld) - do (n,) $ reflect $ fld ast Ah, I forgot one more 'do' to override the stronger binding of $: (n,) $ do reflect $ fld ast Great satisfaction! I killed all

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-31 Thread Erik Hesselink
On Fri, Jul 26, 2013 at 6:44 PM, Andreas Abel andreas.a...@ifi.lmu.de wrote: mapSnd f = (id *** f) As a very small aside, this is just `second` from Control.Arrow. Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-31 Thread Edward Kmett
Or fmap in this case =) On Wed, Jul 31, 2013 at 11:33 AM, Erik Hesselink hessel...@gmail.comwrote: On Fri, Jul 26, 2013 at 6:44 PM, Andreas Abel andreas.a...@ifi.lmu.de wrote: mapSnd f = (id *** f) As a very small aside, this is just `second` from Control.Arrow. Erik

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-26 Thread Siraaj Khandkar
On 07/23/2013 03:37 PM, i c wrote: let's consider the following: let fd = Unix.open ... let fd = Unix.open ... At this point one file descriptor cannot be closed. Static analysis will have trouble catching these bugs, so do humans. Disallowing variable shadowing prevents this. The two fd occur

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-26 Thread Andreas Abel
Mmh, true, for polymorphic definitions there is not a lot to see. This probably diminishes the applicability of a strictness analysis quite a bit. Maybe it is entirely useless at this point. It would make more sense after whole-program optimization. Ghc does not have this, I heard the

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-26 Thread Andreas Abel
On 25.07.2013 09:09, o...@okmij.org wrote: Here is a snippet from a real code that could benefit from non-recursive let. The example is notable because it incrementally constructs not one but two structures (both maps), ast and headers. The maps are constructed in a bit interleaved fashion, and

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-25 Thread oleg
ivan.chollet wrote: let's consider the following: let fd = Unix.open ... let fd = Unix.open ... At this point one file descriptor cannot be closed. Static analysis will have trouble catching these bugs, so do humans. Both sentences express false propositions. The given code, if Haskell,

[Haskell-cafe] Proposal: Non-recursive let

2013-07-25 Thread oleg
Here is a snippet from a real code that could benefit from non-recursive let. The example is notable because it incrementally constructs not one but two structures (both maps), ast and headers. The maps are constructed in a bit interleaved fashion, and stuffing them into the same State would be

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-25 Thread Richard A. O'Keefe
On 25/07/2013, at 7:09 PM, o...@okmij.org wrote: Here is a snippet from a real code that could benefit from non-recursive let. [[A big blob of extremely dense code.]] _Nothing_ is going to make that easy to read. And I say that as someone who loves Haskell and is in *awe* of Oleg. I mean,

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-25 Thread Tom Ellis
On Thu, Jul 25, 2013 at 07:34:55PM +1200, Richard A. O'Keefe wrote: It's a queer thing, I always feel that the advice about keeping function bodies small is patronising nonsense for beginners and that *my* code is perfectly readable no matter how big it is, but end up wishing that *other*

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-25 Thread David Fox
On Wed, Jul 24, 2013 at 1:11 AM, Andreas Abel andreas.a...@ifi.lmu.de wrote: On 23.07.13 4:34 AM, Richard A. O'Keefe wrote: On 22/07/2013, at 8:14 PM, Andreas Abel wrote: Just today, my student asked me why the following program does nothing: Did you ask your student why their code should

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-25 Thread i c
Although your post is a bit trollish, I answer below to clear any confusion. On Thu, Jul 25, 2013 at 7:18 AM, o...@okmij.org wrote: ivan.chollet wrote: let's consider the following: let fd = Unix.open ... let fd = Unix.open ... At this point one file descriptor cannot be closed. Static

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-25 Thread Edward Kmett
I'm just going to say that I'd rather we didn't resort to calling each others trolls. I happen to disagree with Oleg on this particular issue and find that it is better resolved by just using -Wall or a 2-line combinator, but I find that across the breadth and depth of issues in the Haskell

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-24 Thread Andreas Abel
On 23.07.13 4:34 AM, Richard A. O'Keefe wrote: On 22/07/2013, at 8:14 PM, Andreas Abel wrote: Just today, my student asked me why the following program does nothing: Did you ask your student why their code should not be torn into pieces, burned to ashes, and incorporated into a pot for

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-24 Thread Andreas Abel
Sure. I have not looked a concrete strictness analyses, but I expect they would treat Conat differently than Integer. In particular, x does *not* appear strictly in S x if S is a lazy constructor. On 22.07.13 4:54 PM, Edward Kmett wrote: let x = x +1 is perfectly cromulent when x is

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-24 Thread Edward Kmett
You only have a Num constraint when type checking that code: (+) :: Num a = a - a - a For better or worse, you don't get strictness in the type signatures in Haskell. We do not separate codata from data here. Without knowing about the particular instance of Num and even the direction of

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-23 Thread John van Groningen
On 22-7-2013 17:09, i c wrote: On Wed, Jul 10, 2013 at 9:47 AM,o...@okmij.org wrote: Jon Fairbairn wrote: It just changes forgetting to use different variable names because of recursion (which is currently uniform throughout the language) to forgetting to use non recursive let instead of

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-23 Thread John van Groningen
| ~(x,s) = foo 1 [] , ~(y,s) = bar x s , ~(z,s) = baz x y s = ... in my previous message should be: | ~(x,s) - foo 1 [] , ~(y,s) - bar x s , ~(z,s) - baz x y s = ... ___ Haskell-Cafe mailing list

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-23 Thread Bardur Arantsson
On 2013-07-22 17:09, i c wrote: Usage of shadowing is generally bad practice. It is error-prone. Hides obnoxious bugs like file descriptors leaks. These claims need to be substantiated, I think. (Not that I disagree, I just think that asserting this without evidence isn't going to convince

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-23 Thread i c
let's consider the following: let fd = Unix.open ... let fd = Unix.open ... At this point one file descriptor cannot be closed. Static analysis will have trouble catching these bugs, so do humans. Disallowing variable shadowing prevents this. The two fd occur in different contexts and should

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-23 Thread David Thomas
It strikes me as unlikely static analysis would be confused by shadowing. On Tue, Jul 23, 2013 at 12:37 PM, i c ivan.chol...@gmail.com wrote: let's consider the following: let fd = Unix.open ... let fd = Unix.open ... At this point one file descriptor cannot be closed. Static analysis

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-23 Thread Donn Cave
quoth David Thomas davidleotho...@gmail.com, It strikes me as unlikely static analysis would be confused by shadowing. Not to mention that the example only created two expressions of type IO Fd? (I.e., no file descriptors were opened, let alone leaked.) But in any case, I would have guessed

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-23 Thread Bardur Arantsson
On 2013-07-23 21:37, i c wrote: let's consider the following: let fd = Unix.open ... let fd = Unix.open ... At this point one file descriptor cannot be closed. Static analysis will have trouble catching these bugs, so do humans. Disallowing variable shadowing prevents this. The two fd

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-23 Thread i c
Static analysis is not confused by shadowing, it is confused by the file descriptor leak, which it can't find in the general case. Static analysis can only go as far as warning you that some variables are shadowed, and you will ignore such warning since you're doing variable shadowing purposely.

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-22 Thread Richard A. O'Keefe
On 21/07/2013, at 7:36 AM, Evan Laforge wrote: Just by coincidence, I recently wrote this: This is a BEAUTIFUL example. I think we may disagree about what it's an example OF, however. I found the code a little difficult to follow, but when that's fixed up, there's no longer any reason to want

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-22 Thread Andreas Abel
Just today, my student asked me why the following program does nothing: {-# LANGUAGE CPP, GeneralizedNewtypeDeriving, BangPatterns #-} import Control.Monad import System.IO.Unsafe import Data.Array.IO import Data.IORef import Debug.Trace type LinearArray a = (Int, IORef Int, IOArray Int a)

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-22 Thread Andreas Abel
On 20.07.13 9:36 PM, Evan Laforge wrote: However, I'm also not agitating for a non-recursive let, I think that ship has sailed. Besides, if it were added people would start wondering about non-recursive where, and it would introduce an exception to haskell's pretty consistently

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-22 Thread MigMit
On Jul 22, 2013, at 12:27 PM, Andreas Abel andreas.a...@ifi.lmu.de wrote: On 20.07.13 9:36 PM, Evan Laforge wrote: However, I'm also not agitating for a non-recursive let, I think that ship has sailed. Besides, if it were added people would start wondering about non-recursive where, and it

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-22 Thread Andreas Abel
On 22.07.2013 10:50, MigMit wrote: On Jul 22, 2013, at 12:27 PM, Andreas Abel andreas.a...@ifi.lmu.de wrote: On 20.07.13 9:36 PM, Evan Laforge wrote: However, I'm also not agitating for a non-recursive let, I think that ship has sailed. Besides, if it were added people would start wondering

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-22 Thread Edward Kmett
let x = x +1 is perfectly cromulent when x is sufficiently lazy, e.g. in the one point compactification of the naturals: data Conat = S Conat | Z There it represents infinity with proper sharing. -Edward On Jul 22, 2013, at 10:24 AM, Andreas Abel andreas.a...@ifi.lmu.de wrote: On

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-22 Thread i c
On Wed, Jul 10, 2013 at 9:47 AM, o...@okmij.org wrote: Jon Fairbairn wrote: It just changes forgetting to use different variable names because of recursion (which is currently uniform throughout the language) to forgetting to use non recursive let instead of let. Let me bring to the

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-22 Thread Richard A. O'Keefe
On 22/07/2013, at 8:14 PM, Andreas Abel wrote: Just today, my student asked me why the following program does nothing: Did you ask your student why their code should not be torn into pieces, burned to ashes, and incorporated into a pot for radioactive waste? All those occurrences of

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-20 Thread Evan Laforge
On Tue, Jul 16, 2013 at 5:20 PM, Richard A. O'Keefe o...@cs.otago.ac.nz 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.

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-18 Thread Andreas Abel
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 .45% of

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-17 Thread Markus Läll
For what it's worth, I think a non-recursive in the language would just bring more confusion, in forums, IRC and whereever. The benefits don't seem important at all, and the same effect can be achieved through other means. On Wed, Jul 17, 2013 at 2:20 AM, Richard A. O'Keefe o...@cs.otago.ac.nz

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-17 Thread 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

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-17 Thread Edward Kmett
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

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-17 Thread Edward Kmett
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 .45% 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,

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-16 Thread Andreas Abel
Ah, now I have the solution: {-# LANGUAGE CPP #-} (|) = flip ($) #define LET(p, e) (e) | \ (p) - bla = LET(x, 5) LET(Just x, Just (x+1)) x #define MLET(p, e) (e) | \ (p) - do main = do MLET((x, y), (5, 3)) print (x + y) Beautiful, ain't it? Sigh. --Andreas On 11.07.2013

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-16 Thread Timon Gehr
On 07/11/2013 08:37 AM, AntC wrote: oleg at okmij.org writes: ... In Haskell I'll have to uniquely number the s's: let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ... and re-number them if I insert a new statement. I once wrote about

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-16 Thread Richard A. O'Keefe
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

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-11 Thread AntC
oleg at okmij.org writes: ... In Haskell I'll have to uniquely number the s's: let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ... and re-number them if I insert a new statement. I once wrote about 50-100 lines of code with the

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-11 Thread Edward Kmett
On Wed, Jul 10, 2013 at 3:47 AM, o...@okmij.org wrote: Jon Fairbairn wrote: It just changes forgetting to use different variable names because of recursion (which is currently uniform throughout the language) to forgetting to use non recursive let instead of let. Let me bring to the

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-11 Thread Carter Schonwald
Yup. Nested cases *are* non recursive lets. (Can't believe I forgot about that ) On Thursday, July 11, 2013, Edward Kmett wrote: On Wed, Jul 10, 2013 at 3:47 AM, o...@okmij.org javascript:_e({}, 'cvml', 'o...@okmij.org'); wrote: Jon Fairbairn wrote: It just changes forgetting to use

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-11 Thread Andreas Abel
I can do this without extra indentation: (|) = flip ($) f = 5 | \ x - 6 | \ y - x + y Non-recursive let is as superfluous as the do-notation. On 11.07.2013 17:40, Carter Schonwald wrote: Yup. Nested cases *are* non recursive lets. (Can't believe I forgot about that ) On

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-11 Thread Edward Kmett
Lens even supplies this as () On Thu, Jul 11, 2013 at 5:18 PM, Andreas Abel andreas.a...@ifi.lmu.dewrote: I can do this without extra indentation: (|) = flip ($) f = 5 | \ x - 6 | \ y - x + y Non-recursive let is as superfluous as the do-notation. On 11.07.2013 17:40,

[Haskell-cafe] Proposal: Non-recursive let

2013-07-10 Thread oleg
Jon Fairbairn wrote: It just changes forgetting to use different variable names because of recursion (which is currently uniform throughout the language) to forgetting to use non recursive let instead of let. Let me bring to the record the message I just wrote on Haskell-cafe

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-10 Thread Ezra e. k. Cooper
I support Oleg's proposal. A shadowing, non-recursive let would be a useful tool. As starter suggestions for the keyword or syntax, I submit: let new x = expr in body -- Not the old x! let shadowing x = expr in body shadow x = expr in body let x =! expr in body -- The explosive

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-10 Thread Ertugrul Söylemez
Ezra e. k. Cooper e...@ezrakilty.net wrote: As starter suggestions for the keyword or syntax, I submit: let new x = expr in body -- Not the old x! It's not the old x in either case (recursive and non-recursive). let shadowing x = expr in body shadow x = expr in body It's

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-10 Thread Carter Schonwald
theres a very simple way to do non recursive let already! do notation in the identity monad. I use it quite a lot lately. On Wed, Jul 10, 2013 at 1:49 PM, Ertugrul Söylemez e...@ertes.de wrote: Ezra e. k. Cooper e...@ezrakilty.net wrote: As starter suggestions for the keyword or syntax, I

Re: [Haskell-cafe] Proposal: Non-recursive let

2013-07-10 Thread Andreas Abel
On 10.07.13 9:31 PM, Carter Schonwald wrote: theres a very simple way to do non recursive let already! do notation in the identity monad. I use it quite a lot lately. Yeah, the hack x - return $ e instead of let x = e has been discussed already. If you put everything into the Identity