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
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
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
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
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
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
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,
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,
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*
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
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
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
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
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
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
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
| ~(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
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
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
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
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
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
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.
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
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)
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
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
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
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
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
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
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.
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
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
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
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
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,
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
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
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
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
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
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
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
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,
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
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
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
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
49 matches
Mail list logo