Re: [Haskell-cafe] Conduit versions of wai and warp?
On Thu, Jan 19, 2012 at 5:26 AM, Michael Snoyman mich...@snoyman.comwrote: We can still have a conduit-based version of WAI and Warp, even if an underlying package uses enumerator. The enumerator usage from asn1-data doesn't leak into WAI or Warp at all[1]. We could ask Vincent to consider moving over to attoparsec-conduit instead, but I don't think there's any strong need for this. Speaking of the migration issue; it should be possible to have an enumerator - conduit wrapper library to help people continue to use their enumerator-based code for awhile (and vice-versa). G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit versions of wai and warp?
On 01/19/2012 08:14 AM, Gregory Collins wrote:
Speaking of the migration issue; it should be possible to have an
enumerator - conduit wrapper library to help people continue to use
their enumerator-based code for awhile (and vice-versa).
A bit out of topic and definitely not answering the question, but for asn1-data,
i want to move away from the data feeding business, and just relying on the
attoparsec API.
That let the user choose the feeding style by plugin either an existing
attoparsec
plugin package (attoparsec-{conduit,enumerator,iteratee}) or dealing with the
Result
type directly.
This is also possible when using cereal (Data.Serialize).
I think more libraries in the enumerator camp or iteratee camp should look if
they need
to control input or not. unless there's something i missed :-)
--
Vincent @vincenthz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] black Wikipedia
John Meacham j...@repetae.net writes: now, you might say we can just move hackage out of the US This might actually make things worse. The President's office is against hurting US industry, and wants it to be mainly used to attack foreign sites. They will not only order takedowns, but use DNS and ICANN to enforce this policy. Not only that, but the proponents are not just hollywood, it is anyone that feels they will have an advantage with the ability to bully internet sites. For instance, monster cable The scientology church. Politicians. Apparently, Bush considered bombing Al Jazeera, you can imagine how long it would take before it got blocked for copyright violations. The problem is bigger than just free speech (as if that isn't big enough) - it's yet another presumed guilty, preemptive strike law. Patents are similar, even if you do nothing wrong, heavyweights (e.g. Google) can extort smaller players (e.g. me) by simply threatening to sue. Even if they have no chance to win, I simply cannot afford to play, so I have no option except to comply with their demands. SOPA is just the latest and most blatant in the series, trying to secure the entertainment industry the same power over the Internet. That the American Congress is working so hard to place this kind of power in the hands of a relatively small industry -- well, we can all draw our own conclusions. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit versions of wai and warp?
On Thu, Jan 19, 2012 at 10:35 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/19/2012 08:14 AM, Gregory Collins wrote:
Speaking of the migration issue; it should be possible to have an
enumerator - conduit wrapper library to help people continue to use
their enumerator-based code for awhile (and vice-versa).
A bit out of topic and definitely not answering the question, but for
asn1-data,
i want to move away from the data feeding business, and just relying on the
attoparsec API.
That let the user choose the feeding style by plugin either an existing
attoparsec
plugin package (attoparsec-{conduit,enumerator,iteratee}) or dealing with
the Result
type directly.
This is also possible when using cereal (Data.Serialize).
I think more libraries in the enumerator camp or iteratee camp should look
if they need
to control input or not. unless there's something i missed :-)
--
Vincent @vincenthz
That's the reason, for example, that zlib-bindings exists. It's a
mid-level binding to the zlib C library. I wouldn't want to write code
against it in general, but it makes it very easy to create zlib-enum
and zlib-conduit.
Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit versions of wai and warp?
On Thu, Jan 19, 2012 at 10:14 AM, Gregory Collins g...@gregorycollins.net wrote: On Thu, Jan 19, 2012 at 5:26 AM, Michael Snoyman mich...@snoyman.com wrote: We can still have a conduit-based version of WAI and Warp, even if an underlying package uses enumerator. The enumerator usage from asn1-data doesn't leak into WAI or Warp at all[1]. We could ask Vincent to consider moving over to attoparsec-conduit instead, but I don't think there's any strong need for this. Speaking of the migration issue; it should be possible to have an enumerator - conduit wrapper library to help people continue to use their enumerator-based code for awhile (and vice-versa). I think it's easier said than done. Some conversions should be straight-forward: turning a Source into an Enumerator, for example. But others won't be possible without dirty hacks (e.g., Enumerator to Source will likely require forking a thread and using Chan), while others may be completely impossible (Enumeratee to Conduit). I agree such a package is a good idea, and I'd be happy to help anyone who wants to step up to the plate on it, but I'm not very hopeful that it will be incredibly useful. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is there a way to do *allocation* profiling with a breakdown by type?
Hi, I've got a program that seems to spend much of its time allocating short-lived objects, which therefore don't show up in +RTS -hy or alike. Is there a way to get a breakdown by type of the objects that are being *allocated* but not necessarily retained (disappear after gen0)? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal-install bootstrap.sh
I've just spent most of a morning trying to get bootstrap.sh from the cabal-install package to work. The trick is to use ghc-pkg init pathname to initialise the package file - simply adding an empty package file or directory doesn't work. Whoever is responsible for cabal-install, could you please update the README to reflect this requirement. Thanks - Will ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Vector (or List) to CArray?
Hello, I'm trying to use the fftw binding, and its functions operate on CArrays of Complex. My data is coming from hsndfile, so it starts out as a Vector of Double. How do I convert this data to CArray? The API functions in the CArray module don't seem to indicate how. Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vector (or List) to CArray?
On 19.01.2012 22:15, Dominic Espinosa wrote: Hello, I'm trying to use the fftw binding, and its functions operate on CArrays of Complex. My data is coming from hsndfile, so it starts out as a Vector of Double. How do I convert this data to CArray? The API functions in the CArray module don't seem to indicate how. I think only way is to go though lists. CArray and vector package use different primitives. listArray (0, V.length v) $ V.toList v ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vector (or List) to CArray?
On Thu, Jan 19, 2012 at 1:15 PM, Dominic Espinosa dces...@fastmail.fm wrote: Hello, I'm trying to use the fftw binding, and its functions operate on CArrays of Complex. My data is coming from hsndfile, so it starts out as a Vector of Double. How do I convert this data to CArray? The API functions in the CArray module don't seem to indicate how. Thanks. I've not tried this, but I would expect to be able to use http://hackage.haskell.org/package/hsndfile-vector-0.4.0, and then use the ForeignPtr that lives inside the Vector the to build a CArray. Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] partial type annotations
Dear all, I wanted to voice support for a partial type annotations. Here's my usage scenario: I have a monad for an imperative EDSL, which has an associated expression data type, class (Monad m, Expression (ExprTyp m)) = MyDSLMonad m where data ExprTyp m :: * - * and you write imperative EDSL code like so, my_code_block = do x - instruction1 y - instruction2 (x + x) ... I want the user to be able to annotate x is an Integer. However, to do that now, one has to now add a type signature for my_code_block like so, so that the $m$ variable is in scope, my_code_block :: forall m. MyDSLMonad m = m () my_code_block = do x :: ExprTyp m Integer - instruction1 ... If such a feature were available, one could write a nice type synonym Expr and use it like so, type Expr a = ExprTyp _ a my_code_block = do x :: Expr Integer - instruction1 Suggestions for workarounds are appreciated. I created an `asExprTypeOf`, similar to Prelude's `asExprTyp`, but I don't like the syntax as much. Some previous discussion * http://www.haskell.org/pipermail/haskell/2002-April/009409.html * (a reply) http://www.haskell.org/pipermail/haskell/2002-April/009413.html * http://hackage.haskell.org/trac/haskell-prime/wiki/PartialTypeAnnotations cheers, Nicholas — https://ntung.com — 4432-nstung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial type annotations
On 20.01.2012 00:37, Nicholas Tung wrote: Dear all, I wanted to voice support for a partial type annotations. Here's my usage scenario: I have a monad for an imperative EDSL, which has an associated expression data type, I wanted such extension more than once. For me it's useful when compiler can almost infer type and only few type variables are actually required. Now I have to either type full signature or invert functions a la `asTypeOf' class (Monad m, Expression (ExprTyp m)) = MyDSLMonad m where data ExprTyp m :: * - * and you write imperative EDSL code like so, my_code_block = do x - instruction1 y - instruction2 (x + x) ... I want the user to be able to annotate x is an Integer. However, to do that now, one has to now add a type signature for my_code_block like so, so that the $m$ variable is in scope, my_code_block :: forall m. MyDSLMonad m = m () my_code_block = do x :: ExprTyp m Integer - instruction1 Actually it should be my_code_block :: ... my_code_block = do x :: Integer - instruction1 -- Require ScopedTypeVariables or x - instruction1 :: Expr Integer or with partial type signatures x - instruction1 :: _ _ Integer or wiht x - instruction1 y - instrunctio2 (x + x :: Integer) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Not an isomorphism, but what to call it?
I have two types A and B, and I want to express that the composition of two functions f :: B - A and g :: A - B gives me the identity idA = f . g :: A - A. I don't need g . f :: B - B to be the identity on B, so I want a weaker statement than isomorphism. I understand that: (1) If I look at it from the perspective of f, then g is the right inverse or section (or split monomorphism). (2) If I look at from g, then f is the left inverse or retraction (or split epimorphism). But I just want two functions that give me an identity on one of the two types and I don't care which function's perspective I'm looking at it from. Is there a word for that? Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not an isomorphism, but what to call it?
On Thu, Jan 19, 2012 at 3:24 PM, Sean Leather leat...@cs.uu.nl wrote: I have two types A and B, and I want to express that the composition of two functions f :: B - A and g :: A - B gives me the identity idA = f . g :: A - A. I don't need g . f :: B - B to be the identity on B, so I want a weaker statement than isomorphism. I understand that: (1) If I look at it from the perspective of f, then g is the right inverse or section (or split monomorphism). (2) If I look at from g, then f is the left inverse or retraction (or split epimorphism). But I just want two functions that give me an identity on one of the two types and I don't care which function's perspective I'm looking at it from. Is there a word for that? I don't think it makes sense to say you want one label for the situation when looking from either end - the relation you're labeling is non-symmetric. Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not an isomorphism, but what to call it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2012 07:24 AM, Sean Leather wrote: I have two types A and B, and I want to express that the composition of two functions f :: B - A and g :: A - B gives me the identity idA = f . g :: A - A. I don't need g . f :: B - B to be the identity on B, so I want a weaker statement than isomorphism. I understand that: (1) If I look at it from the perspective of f, then g is the right inverse or section (or split monomorphism). (2) If I look at from g, then f is the left inverse or retraction (or split epimorphism). But I just want two functions that give me an identity on one of the two types and I don't care which function's perspective I'm looking at it from. Is there a word for that? Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe It is not clear to me exactly what you are asking, so shot in the dark: injection or surjection? - -- Tony Morris http://tmorris.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPGJNXAAoJEPxHMY3rBz0PHt0IAKP1lVcfDXZm00h4W1WQPDBT h6LB9nLlp0cgAh5CH06FsdQFqdtDVJNMkV7/9q3H/wTFOoscZHCTigr1G+vE/kA8 lh1/Gb3caQByt6rWkgD79998FL5ZCBdHN2HYh1o/RPBwA/BYxA041P92pE0EFTKB 1oylh5ldUfv8rEzvHhQVw0USrJ11uiZfn/T3+UrO2s2xLQZS1oTWNZhsKMccjB95 tYaqEw+20Q+8yBanVnDJFOqD3yPXIRBHkTSJTOFO+Y++oen4gXUzSJJ2lkpXLECE ojMNHD/9Yh43gCm1Jq3Wuz5B6mr+v+RTRuLkxiVMsK7wxW+lfmOgeMyxHyr8pxU= =aPtB -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vector (or List) to CArray?
On Thu, Jan 19, 2012 at 10:15 AM, Dominic Espinosa dces...@fastmail.fm wrote: Hello, I'm trying to use the fftw binding, and its functions operate on CArrays of Complex. My data is coming from hsndfile, so it starts out as a Vector of Double. How do I convert this data to CArray? The API functions in the CArray module don't seem to indicate how. My first recommendation would be to use the vector-fftw package, which uses Vectors instead of CArrays. But as the author of that package I may be a bit biased. Alternately, converting between CArrays and Vectors isn't too hard if you want to do it directly. For example, you can convert from Vector to CArray by using Data.Vector.Storable.unsafeToForeignPtr and Data.Array.CArray.Base.unsafeForeignPtrToIOCArray. Other functions in those modules will let you go in the other direction. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not an isomorphism, but what to call it?
Am 19.01.2012 um 22:24 schrieb Sean Leather: I have two types A and B, and I want to express that the composition of two functions f :: B - A and g :: A - B gives me the identity idA = f . g :: A - A. I don't need g . f :: B - B to be the identity on B, so I want a weaker statement than isomorphism. I understand that: (1) If I look at it from the perspective of f, then g is the right inverse or section (or split monomorphism). (2) If I look at from g, then f is the left inverse or retraction (or split epimorphism). But I just want two functions that give me an identity on one of the two types and I don't care which function's perspective I'm looking at it from. Is there a word for that? If (g . f) is a closure operator for some ordering on B, then f,g is a Galois insertion, a special case of Galois connection. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not an isomorphism, but what to call it?
A is a retract of B. http://nlab.mathforge.org/nlab/show/retract g is the section, f is the rectraction. You seem to have it already. The definition needn't be biased toward one of the functions. On Thu, Jan 19, 2012 at 4:24 PM, Sean Leather leat...@cs.uu.nl wrote: I have two types A and B, and I want to express that the composition of two functions f :: B - A and g :: A - B gives me the identity idA = f . g :: A - A. I don't need g . f :: B - B to be the identity on B, so I want a weaker statement than isomorphism. I understand that: (1) If I look at it from the perspective of f, then g is the right inverse or section (or split monomorphism). (2) If I look at from g, then f is the left inverse or retraction (or split epimorphism). But I just want two functions that give me an identity on one of the two types and I don't care which function's perspective I'm looking at it from. Is there a word for that? Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial type annotations
Oleg has described a grody hack which achieves this effect. http://okmij.org/ftp/Haskell/types.html#partial-sigs I agree more first class support for this would be nice. Edward Excerpts from Nicholas Tung's message of Thu Jan 19 15:37:28 -0500 2012: Dear all, I wanted to voice support for a partial type annotations. Here's my usage scenario: I have a monad for an imperative EDSL, which has an associated expression data type, class (Monad m, Expression (ExprTyp m)) = MyDSLMonad m where data ExprTyp m :: * - * and you write imperative EDSL code like so, my_code_block = do x - instruction1 y - instruction2 (x + x) ... I want the user to be able to annotate x is an Integer. However, to do that now, one has to now add a type signature for my_code_block like so, so that the $m$ variable is in scope, my_code_block :: forall m. MyDSLMonad m = m () my_code_block = do x :: ExprTyp m Integer - instruction1 ... If such a feature were available, one could write a nice type synonym Expr and use it like so, type Expr a = ExprTyp _ a my_code_block = do x :: Expr Integer - instruction1 Suggestions for workarounds are appreciated. I created an `asExprTypeOf`, similar to Prelude's `asExprTyp`, but I don't like the syntax as much. Some previous discussion * http://www.haskell.org/pipermail/haskell/2002-April/009409.html * (a reply) http://www.haskell.org/pipermail/haskell/2002-April/009413.html * http://hackage.haskell.org/trac/haskell-prime/wiki/PartialTypeAnnotations cheers, Nicholas — https://ntung.com — 4432-nstung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial type annotations
On Thu, Jan 19, 2012 at 13:16, Aleksey Khudyakov alexey.sklad...@gmail.comwrote: On 20.01.2012 00:37, Nicholas Tung wrote: Dear all, I wanted to voice support for a partial type annotations. Here's my usage scenario: I have a monad for an imperative EDSL, which has an associated expression data type, I wanted such extension more than once. For me it's useful when compiler can almost infer type and only few type variables are actually required. Now I have to either type full signature or invert functions a la `asTypeOf' class (Monad m, Expression (ExprTyp m)) = MyDSLMonad m where data ExprTyp m :: * - * and you write imperative EDSL code like so, my_code_block = do x - instruction1 y - instruction2 (x + x) ... I want the user to be able to annotate x is an Integer. However, to do that now, one has to now add a type signature for my_code_block like so, so that the $m$ variable is in scope, my_code_block :: forall m. MyDSLMonad m = m () my_code_block = do x :: ExprTyp m Integer - instruction1 Actually it should be my_code_block :: ... my_code_block = do x :: Integer - instruction1 -- Require ScopedTypeVariables or x - instruction1 :: Expr Integer or with partial type signatures x - instruction1 :: _ _ Integer or wiht x - instruction1 y - instrunctio2 (x + x :: Integer) It's not important, but my example was what I meant -- I am creating an EDSL, and the values flowing through are actually syntax trees representing expressions. For example, x + x might create a tree with top node +, and subtrees as x. We then have type instruction1 :: m (ExprTyp m Integer) or using the shorthand, if there were partial signatures, instruction1 :: m (Expr Integer) regards, Nicholas — https://ntung.com — 4432-nstung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial type annotations
On Thu, Jan 19, 2012 at 15:02, Edward Z. Yang ezy...@mit.edu wrote: Oleg has described a grody hack which achieves this effect. http://okmij.org/ftp/Haskell/types.html#partial-sigs I agree more first class support for this would be nice. Edward That's an amusing hack, but does it provide anything on top of `asTypeOf`? I'd rather write Oleg's first example as, isOrd :: Ord a = a isOrd = undefined asOrd = flip asTypeOf isOrd f x = Just $ asOrd x -- now has type Ord a = a - Maybe a Actually, using view patterns, one can get closer to the code I wanted to write, f (asOrd - x) = Just x comp x = do (asOrd - y) - return x return y But, ideally, I want type expressions to appear as types, not value functions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
Today I learned (tldr; TIL) that the fail in the Monad class was added as a hack to deal with the consequences of the decision to remove unfailable patterns from the language. I will attempt to describe the story as I have picked it up from reading around, but please feel free to correct me on the details. :-) An unfailable pattern (which is a generalization of an irrefutable pattern) is a pattern which can never fail (excluding the possibility of _|_), such as let (x,y) = pair Before fail was a method of the Monad class, using refutable patterns in a monad required the type to be an instance of MonadZero (that is, MonadPlus without the plus), so that for example do Just x - m required that the monad be an instance of MonadZero. If you avoided such patterns, your Monad did not have to have this instance, so that for example do (x,y) - pair would not require MonadZero because the pattern is unfailable. To me this seems like a lovely way of handling the whole matter, and much improved over the incredibly ugly wart of having a fail method in the Monad class. In fact, I think I remember people on this list and in other forums occasionally bringing something like this approach up as a way of getting rid of the fail wart. So my question is, why did we go to all of the trouble to transition away from the MonadZero approach to the current system to begin with? What was so bad about unfailable patterns that it was decided to remove them and in doing so replace MonadZero with a mandatory fail method in Monad? I mean, this *is* Haskell, so my safest assumption is that smart people were involved in making this decision and therefore the reasons much have been really good (or at least, seemed good given the information at the time). :-) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
Hello Gregory,
The original (1998!) conversation can be found here:
http://www.mail-archive.com/haskell@haskell.org/msg03002.html
I think Simon Peyton-Jones' example really sums up the whole issue:
But [MonadZero] really sticks in my craw. How can we explain this:
f :: Monad m = m (a,b) - m a
f m1 = do { x - m1; return (fst x) }
g :: MonadZero m = m (a,b) - m a
g m1 = do { (a,b) - m1; return a }
h :: Monad m = m (a,b) - m a
h m1 = do { ~(a,b) - m1; return a }
Why must g be in MonadZero? Because the pattern (a,b) is refutable (by
bottom).
In my opinion, the /flexibility/ that was added by mfail was the real
mistake; we should have just had incomplete - matches be handled the same
way ordinary incomplete pattern matches were accomodated, and figured out
how to nicely allow for multiple patterns in do-notation. In other words,
MonadZero has no place in dealing with pattern match failure!
But this ship has long sailed.
Cheers,
Edward
Excerpts from Gregory Crosswhite's message of Thu Jan 19 21:47:42 -0500 2012:
Today I learned (tldr; TIL) that the fail in the Monad class was added
as a hack to deal with the consequences of the decision to remove
unfailable patterns from the language. I will attempt to describe the
story as I have picked it up from reading around, but please feel free
to correct me on the details. :-)
An unfailable pattern (which is a generalization of an irrefutable
pattern) is a pattern which can never fail (excluding the possibility of
_|_), such as
let (x,y) = pair
Before fail was a method of the Monad class, using refutable patterns
in a monad required the type to be an instance of MonadZero (that is,
MonadPlus without the plus), so that for example
do Just x - m
required that the monad be an instance of MonadZero. If you avoided
such patterns, your Monad did not have to have this instance, so that
for example
do (x,y) - pair
would not require MonadZero because the pattern is unfailable.
To me this seems like a lovely way of handling the whole matter, and
much improved over the incredibly ugly wart of having a fail method in
the Monad class. In fact, I think I remember people on this list and in
other forums occasionally bringing something like this approach up as a
way of getting rid of the fail wart.
So my question is, why did we go to all of the trouble to transition
away from the MonadZero approach to the current system to begin with?
What was so bad about unfailable patterns that it was decided to
remove them and in doing so replace MonadZero with a mandatory fail
method in Monad? I mean, this *is* Haskell, so my safest assumption is
that smart people were involved in making this decision and therefore
the reasons much have been really good (or at least, seemed good given
the information at the time). :-)
Cheers,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
Oh, I'm sorry! On a closer reading of your message, you're asking not only asking why 'fail' was added to Monad, but why unfailable patterns were removed. Well, from the message linked: In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable (it can't fail to match). But the Haskell 1.4 story is unattractive becuase a) we have to introduce the (new) concept of unfailable b) if you add an extra constructor to a single-constructor type then pattern matches on the original constructor suddenly become failable (b) is a real killer: suppose that you want to add a new constructor and fix all of the places where you assumed there was only one constructor. The compiler needs to emit warnings in this case, and not silently transform these into failable patterns handled by MonadZero... Edward Excerpts from Gregory Crosswhite's message of Thu Jan 19 21:47:42 -0500 2012: Today I learned (tldr; TIL) that the fail in the Monad class was added as a hack to deal with the consequences of the decision to remove unfailable patterns from the language. I will attempt to describe the story as I have picked it up from reading around, but please feel free to correct me on the details. :-) An unfailable pattern (which is a generalization of an irrefutable pattern) is a pattern which can never fail (excluding the possibility of _|_), such as let (x,y) = pair Before fail was a method of the Monad class, using refutable patterns in a monad required the type to be an instance of MonadZero (that is, MonadPlus without the plus), so that for example do Just x - m required that the monad be an instance of MonadZero. If you avoided such patterns, your Monad did not have to have this instance, so that for example do (x,y) - pair would not require MonadZero because the pattern is unfailable. To me this seems like a lovely way of handling the whole matter, and much improved over the incredibly ugly wart of having a fail method in the Monad class. In fact, I think I remember people on this list and in other forums occasionally bringing something like this approach up as a way of getting rid of the fail wart. So my question is, why did we go to all of the trouble to transition away from the MonadZero approach to the current system to begin with? What was so bad about unfailable patterns that it was decided to remove them and in doing so replace MonadZero with a mandatory fail method in Monad? I mean, this *is* Haskell, so my safest assumption is that smart people were involved in making this decision and therefore the reasons much have been really good (or at least, seemed good given the information at the time). :-) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On 01/20/12 13:23, Edward Z. Yang wrote: In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable (it can't fail to match). But the Haskell 1.4 story is unattractive becuase a) we have to introduce the (new) concept of unfailable b) if you add an extra constructor to a single-constructor type then pattern matches on the original constructor suddenly become failable (b) is a real killer: suppose that you want to add a new constructor and fix all of the places where you assumed there was only one constructor. The compiler needs to emit warnings in this case, and not silently transform these into failable patterns handled by MonadZero... Okay, great, that explains two things that had not been clear to me: first, that the notion of unfailable was not removed from the language so much as not added in the first place, and second, that if unfailable *had* been added to the language then this would have created the serious risk that adding a new constructor to a type could change the meaning of your code by changing formerly irrefutable pattern matches into potential sources of mzeros. Thanks! Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On Thu, Jan 19, 2012 at 10:43 PM, Gregory Crosswhite gcrosswh...@gmail.com wrote: first, that the notion of unfailable was not removed from the language so much as not added in the first place No, this is not correct. Unfailable patterns were specified in Haskell 1.4 (or, they were called failure-free there; they likely existed earlier, too, but I'll leave the research to people who are interested). They were new in the sense that they were introduced only for the purposes of desugaring do/comprehensions, whereas refutable vs. irrefutable patterns need to be talked about for other purposes. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
Aw, that is really suboptimal. Have you filed a bug? Edward Excerpts from Michael Snoyman's message of Thu Jan 19 23:29:59 -0500 2012: On Fri, Jan 20, 2012 at 5:23 AM, Edward Z. Yang ezy...@mit.edu wrote: Oh, I'm sorry! On a closer reading of your message, you're asking not only asking why 'fail' was added to Monad, but why unfailable patterns were removed. Well, from the message linked: In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable (it can't fail to match). But the Haskell 1.4 story is unattractive becuase a) we have to introduce the (new) concept of unfailable b) if you add an extra constructor to a single-constructor type then pattern matches on the original constructor suddenly become failable (b) is a real killer: suppose that you want to add a new constructor and fix all of the places where you assumed there was only one constructor. The compiler needs to emit warnings in this case, and not silently transform these into failable patterns handled by MonadZero... But wait a second... this is exactly the situation we have today! Suppose I write some code: data MyType = Foo test myType = do Foo - myType return () As expected, no warnings. But if I change this unfailable code above to the following failable version: data MyType = Foo | Bar test myType = do Foo - myType return () I *still* get no warnings! We didn't make sure the compiler spits out warnings. Instead, we guaranteed that it *never* will. This has actually been something that bothers me a lot. Whereas everywhere else in my pattern matching code, the compiler can make sure I didn't make some stupid mistake, in do-notation I can suddenly get a runtime error. My opinion is we should either reinstate the MonadZero constraint, or simply can failable pattern matches. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On Fri, Jan 20, 2012 at 6:41 AM, Edward Z. Yang ezy...@mit.edu wrote: Aw, that is really suboptimal. Have you filed a bug? I think it's a feature, not a bug. When dealing with monads that provide nice[1] implementations of `fail`, you can (ab)use this to avoid writing a bunch of case expressions. I remember reading it in one of the first tutorials on Haskell I looked at (four years ago now? you can see how much this bothered me if I still remember that). I admit that there are some use cases where the current behavior is convenient, but I think we're paying too steep a price. If we got rid of this feature entirely, we could (a) get rid of fail and (b) have the compiler warn us about a bunch of errors at compile time. But maybe I should file a feature request: provide an extra warning flag (turned on by -Wall) that will warn when you match on a failable pattern. Essentially, I would want: SomeConstr args - someAction to be interpreted as: temp - someAction case temp of SomeConstr args - Michael [1] For some people's definition of nice, not mine. Edward Excerpts from Michael Snoyman's message of Thu Jan 19 23:29:59 -0500 2012: On Fri, Jan 20, 2012 at 5:23 AM, Edward Z. Yang ezy...@mit.edu wrote: Oh, I'm sorry! On a closer reading of your message, you're asking not only asking why 'fail' was added to Monad, but why unfailable patterns were removed. Well, from the message linked: In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable (it can't fail to match). But the Haskell 1.4 story is unattractive becuase a) we have to introduce the (new) concept of unfailable b) if you add an extra constructor to a single-constructor type then pattern matches on the original constructor suddenly become failable (b) is a real killer: suppose that you want to add a new constructor and fix all of the places where you assumed there was only one constructor. The compiler needs to emit warnings in this case, and not silently transform these into failable patterns handled by MonadZero... But wait a second... this is exactly the situation we have today! Suppose I write some code: data MyType = Foo test myType = do Foo - myType return () As expected, no warnings. But if I change this unfailable code above to the following failable version: data MyType = Foo | Bar test myType = do Foo - myType return () I *still* get no warnings! We didn't make sure the compiler spits out warnings. Instead, we guaranteed that it *never* will. This has actually been something that bothers me a lot. Whereas everywhere else in my pattern matching code, the compiler can make sure I didn't make some stupid mistake, in do-notation I can suddenly get a runtime error. My opinion is we should either reinstate the MonadZero constraint, or simply can failable pattern matches. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
It's not obvious that this should be turned on by -Wall, since you would also trigger errors on uses like: [ x | Just x - xs ] T_T But I do think it ought to be an option. Cheers, Edward Excerpts from Michael Snoyman's message of Thu Jan 19 23:52:10 -0500 2012: On Fri, Jan 20, 2012 at 6:41 AM, Edward Z. Yang ezy...@mit.edu wrote: Aw, that is really suboptimal. Have you filed a bug? I think it's a feature, not a bug. When dealing with monads that provide nice[1] implementations of `fail`, you can (ab)use this to avoid writing a bunch of case expressions. I remember reading it in one of the first tutorials on Haskell I looked at (four years ago now? you can see how much this bothered me if I still remember that). I admit that there are some use cases where the current behavior is convenient, but I think we're paying too steep a price. If we got rid of this feature entirely, we could (a) get rid of fail and (b) have the compiler warn us about a bunch of errors at compile time. But maybe I should file a feature request: provide an extra warning flag (turned on by -Wall) that will warn when you match on a failable pattern. Essentially, I would want: SomeConstr args - someAction to be interpreted as: temp - someAction case temp of SomeConstr args - Michael [1] For some people's definition of nice, not mine. Edward Excerpts from Michael Snoyman's message of Thu Jan 19 23:29:59 -0500 2012: On Fri, Jan 20, 2012 at 5:23 AM, Edward Z. Yang ezy...@mit.edu wrote: Oh, I'm sorry! On a closer reading of your message, you're asking not only asking why 'fail' was added to Monad, but why unfailable patterns were removed. Well, from the message linked: In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable (it can't fail to match). But the Haskell 1.4 story is unattractive becuase a) we have to introduce the (new) concept of unfailable b) if you add an extra constructor to a single-constructor type then pattern matches on the original constructor suddenly become failable (b) is a real killer: suppose that you want to add a new constructor and fix all of the places where you assumed there was only one constructor. The compiler needs to emit warnings in this case, and not silently transform these into failable patterns handled by MonadZero... But wait a second... this is exactly the situation we have today! Suppose I write some code: data MyType = Foo test myType = do Foo - myType return () As expected, no warnings. But if I change this unfailable code above to the following failable version: data MyType = Foo | Bar test myType = do Foo - myType return () I *still* get no warnings! We didn't make sure the compiler spits out warnings. Instead, we guaranteed that it *never* will. This has actually been something that bothers me a lot. Whereas everywhere else in my pattern matching code, the compiler can make sure I didn't make some stupid mistake, in do-notation I can suddenly get a runtime error. My opinion is we should either reinstate the MonadZero constraint, or simply can failable pattern matches. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On Thu, Jan 19, 2012 at 8:53 PM, Edward Z. Yang ezy...@mit.edu wrote: It's not obvious that this should be turned on by -Wall, since you would also trigger errors on uses like: [ x | Just x - xs ] I was going to say, perhaps refutable matches were considered important was because back then list and monad comprehensions were still the same. List-comps is the only place I use refutable matches, but they're extremely handy. I would have suggested that listcomp match failures yield [] but monad ones be errors, but now that list comps and monads are back together again maybe that's not so easy to do... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
As expected, no warnings. But if I change this unfailable code above to the following failable version: data MyType = Foo | Bar test myType = do Foo - myType return () I *still* get no warnings! We didn't make sure the compiler spits out warnings. Instead, we guaranteed that it *never* will. This is actually the right useful behavior. using things like do Just x - xs Just y - ys return (x,y) will do the right thing, failing if xs or ysresults in Nothing. for instance, in the list monad, it will create the cross product of the non Nothing members of the two lists. a parse monad may backtrack and try another route, the IO monad will create a useful (and deterministic/catchable) exception pointing to the exact file and line number of the pattern match. The do notation is the only place in haskell that allows us to hook into the pattern matching mechanism of the language in a general way. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On Jan 20, 2012 8:31 AM, John Meacham j...@repetae.net wrote: As expected, no warnings. But if I change this unfailable code above to the following failable version: data MyType = Foo | Bar test myType = do Foo - myType return () I *still* get no warnings! We didn't make sure the compiler spits out warnings. Instead, we guaranteed that it *never* will. This is actually the right useful behavior. using things like do Just x - xs Just y - ys return (x,y) will do the right thing, failing if xs or ysresults in Nothing. for instance, in the list monad, it will create the cross product of the non Nothing members of the two lists. a parse monad may backtrack and try another route, the IO monad will create a useful (and deterministic/catchable) exception pointing to the exact file and line number of the pattern match. The do notation is the only place in haskell that allows us to hook into the pattern matching mechanism of the language in a general way. John I mention later that this is a feature, not a bug to some people, but I'm not one of them. The convenience of having this feature is IMO far outweighed by the cost of the runtime errors it can produce if you use the pattern matching in the wrong monad (e.g., IO, Reader, Writer...). Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial type annotations
In the spirit of Oleg's hack, but with nicer combinator support, you can use the patch combinators I just uploaded to Hackage (prompted by this thread): http://hackage.haskell.org/package/patch-combinators Your example then becomes: my_code_block = do x - instruction1 -:: tCon (tCon tInteger) y - instruction2 (x + x) The signature `tCon (tCon tInteger)` should be read as the type `_ (_ Integer)`. Alternatively, with ViewPatterns, you can write: my_code_block2 = do (tCon tInteger - x) - instruction1 y - instruction2 (x + x) return y / Emil 2012-01-19 21:37, Nicholas Tung skrev: Dear all, I wanted to voice support for a partial type annotations. Here's my usage scenario: I have a monad for an imperative EDSL, which has an associated expression data type, class (Monad m, Expression (ExprTyp m)) = MyDSLMonad m where data ExprTyp m :: * - * and you write imperative EDSL code like so, my_code_block = do x - instruction1 y - instruction2 (x + x) ... I want the user to be able to annotate x is an Integer. However, to do that now, one has to now add a type signature for my_code_block like so, so that the $m$ variable is in scope, my_code_block :: forall m. MyDSLMonad m = m () my_code_block = do x :: ExprTyp m Integer - instruction1 ... If such a feature were available, one could write a nice type synonym Expr and use it like so, type Expr a = ExprTyp _ a my_code_block = do x :: Expr Integer - instruction1 Suggestions for workarounds are appreciated. I created an `asExprTypeOf`, similar to Prelude's `asExprTyp`, but I don't like the syntax as much. Some previous discussion * http://www.haskell.org/pipermail/haskell/2002-April/009409.html * (a reply) http://www.haskell.org/pipermail/haskell/2002-April/009413.html * http://hackage.haskell.org/trac/haskell-prime/wiki/PartialTypeAnnotations cheers, Nicholas — https://ntung.com — 4432-nstung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On 01/20/12 14:52, Michael Snoyman wrote: Essentially, I would want: SomeConstr args - someAction to be interpreted as: temp - someAction case temp of SomeConstr args - I completely agree; perhaps what we really want though is something more akin to a language extension --- say, DisableMonadFailForRefutablePatterns? Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On Thu, Jan 19, 2012 at 11:11 PM, Dan Doel dan.d...@gmail.com wrote:
No, this is not correct. Unfailable patterns were specified in Haskell
1.4 (or, they were called failure-free there; they likely existed
earlier, too, but I'll leave the research to people who are
interested). They were new in the sense that they were introduced
only for the purposes of desugaring do/comprehensions, whereas
refutable vs. irrefutable patterns need to be talked about for other
purposes.
I should also note: GHC already implements certain unfailable patterns
the 1.4 way when using RebindableSyntax (possibly by accident):
{-# LANGUAGE RebindableSyntax, MonadComprehensions #-}
module Test where
import qualified Prelude
import Prelude (String, Maybe(..))
import Control.Applicative
class Applicative m = Monad m where
(=) :: m a - (a - m b) - m b
return :: Applicative f = a - f a
return = pure
class Monad m = MonadZero m where
mzero :: m a
fail :: String - m a
mzero = fail mzero
fail _ = mzero
foo :: MonadZero m = m (Maybe a) - m a
foo m = do Just x - m
pure x
bar :: Monad m = m (a, b) - m a
bar m = do (x, y) - m
pure x
baz :: MonadZero m = m (Maybe a) - m a
baz m = [ x | Just x - m ]
quux :: Monad m = m (a, b) - m a
quux m = [ x | (x, y) - m ]
It doesn't work for types defined with data, but it works for built-in tuples.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On Fri, Jan 20 2012 at 06:22 +0100, Evan Laforge wrote: On Thu, Jan 19, 2012 at 8:53 PM, Edward Z. Yang ezy...@mit.edu wrote: It's not obvious that this should be turned on by -Wall, since you would also trigger errors on uses like: [ x | Just x - xs ] [...] I would have suggested that listcomp match failures yield [] but monad ones be errors, but now that list comps and monads are back together again maybe that's not so easy to do... Perhaps a generalization of this would be to warn only if fail was inherited by the original Monad typeclass, where it seems obvious that fail takes the role of a ``work-around''. When fail is overwritten one could perhaps assume that calling it is the intended behavior for pattern match failures. Lu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
