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
Or fmap in this case =)
On Wed, Jul 31, 2013 at 11:33 AM, Erik Hesselink wrote:
> On Fri, Jul 26, 2013 at 6:44 PM, Andreas Abel
> wrote:
> > mapSnd f = (id *** f)
>
> As a very small aside, this is just `second` from Control.Arrow.
>
> Erik
>
> ___
>
On Fri, Jul 26, 2013 at 6:44 PM, Andreas Abel 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
http://www.haskell.org/mailman/listinfo/haskell
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
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 Intel
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" occu
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 ecosys
Although your post is a bit trollish, I answer below to clear any confusion.
On Thu, Jul 25, 2013 at 7:18 AM, 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 a
On Wed, Jul 24, 2013 at 1:11 AM, Andreas Abel 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 not b
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* p
On 25/07/2013, at 7:09 PM, 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, if the functi
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 Has
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 recu
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 s
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 radio
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.
Th
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
quoth David Thomas ,
> 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 that the idea here is that
It strikes me as unlikely static analysis would be confused by shadowing.
On Tue, Jul 23, 2013 at 12: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
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 ha
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 an
| ~(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
Haskell-Cafe@haskel
On 22-7-2013 17:09, i c wrote:
On Wed, Jul 10, 2013 at 9:47 AM, 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 bri
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 unsafePer
On Wed, Jul 10, 2013 at 9:47 AM, 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 record t
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 wrote:
> On 22.07.2013 10:50, MigMit wrote:
On 22.07.2013 10:50, MigMit wrote:
On Jul 22, 2013, at 12:27 PM, Andreas Abel
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 whe
On Jul 22, 2013, at 12:27 PM, Andreas Abel 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 would introduce 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 order-independent
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)
in
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
On Tue, Jul 16, 2013 at 5:20 PM, 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."
Just by coi
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 t
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, A
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 le
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 i
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 wrote:
> Brian Marick
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
On 07/11/2013 08:37 AM, AntC wrote:
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
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.2
Lens even supplies this as (&)
On Thu, Jul 11, 2013 at 5:18 PM, Andreas Abel wrote:
> 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, Carte
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
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, 'cvml', 'o...@okmij.org');>> wrote:
>
>>
>> Jon Fairbairn wrote:
>> > It just changes forgetting to use different variable names be
On Wed, Jul 10, 2013 at 3:47 AM, 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 record t
> 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
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
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 wrote:
> "Ezra e. k. Cooper" wrote:
>
> > As starter suggestions for the keyword or syntax, I submit:
> >
> > let new x
"Ezra e. k. Cooper" 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 shadowing in eithe
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 bang
49 matches
Mail list logo
