On 11.06.2015 18:20, Dan Doel wrote:
> I believe a pattern is classified as unfailable there if it is irrefutable or
> refutable only by bottom. Which of course is the distinction here, (x,y) is
> unfailable, but not irrefutable.
Some of the confusion may be because GHC has a function "isIrrefut
This is all well defined in the Haskell 1.4 report. Back then Haskell had
"unfailable" patterns for desugaring do notation, because there was no fail
(it was introduced in H98).
I believe a pattern is classified as unfailable there if it is irrefutable
or refutable only by bottom. Which of course
Quoting the Haskell 2010 Report section 3.17.2: Attempting to match a
pattern can have one of three results: it may fail; it may succeed
...; or it may diverge. Then in paragraph 5:
Matching the pattern con pat1 ... patn against a value, where con is a
constructor defined by data, depends on the v
Ah, I see. Even if you desugar pattern matching against (_, _) in a do
block like you do for multi-constructor data types, ⊥ still does not
result in an invocation of fail, since matching ⊥ against (_, _) leads
to divergence. To illustrate this, let f be defined as follows:
f (_, _) = True
Pattern matching on `undefined` is not like pattern match failure.
Single-constructor types are only special if they're unlifted:
`newtype` and GHC's unboxed tuples are the only examples I know of,
and you can't use unboxed tuples in this context.
On Thu, Jun 11, 2015 at 11:28 AM, Wolfgang Jeltsch
Are you sure that desugaring works this way? If yes, this should be
considered a bug and be fixed, I would say. It is very illogical.
All the best,
Wolfgang
Am Donnerstag, den 11.06.2015, 16:23 +0100 schrieb David Turner:
> AIUI the point about ⊥ and (⊥, ⊥) being different doesn't matter here:
>
AIUI the point about ⊥ and (⊥, ⊥) being different doesn't matter here:
a bind for a single-constructor datatype never desugars in a way that
uses fail (which isn't to say that it can't be undefined)
For instance:
runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String IO ())
thro
Hi David,
thank you very much for this proposal. I think having fail in Monad is
just plain wrong, and I am therefore very happy to see it being moved
out.
I have some remarks, though:
> A class of patterns that are conditionally failable are `newtype`s,
> and single constructor `data` types, wh
On Wed, Jun 10, 2015 at 2:14 PM, Johan Tibell wrote:
> On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka wrote:
>>
>> On 10/06/15 14:22, Johan Tibell wrote:
>> > On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
>> > mailto:dluposchain...@googlemail.com>>
>> > wrote:
>> >
>> > I think ther
On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka wrote:
> On 10/06/15 14:22, Johan Tibell wrote:
> > On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
> > mailto:dluposchain...@googlemail.com>>
> > wrote:
> >
> > I think there are two important consequences of MonadFail. First of
> >
+1 also improves the correctness of the monad laws
On Jun 10, 2015 7:46 AM, "Roman Cheplyaka" wrote:
> On 10/06/15 14:22, Johan Tibell wrote:
> > On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
> > mailto:dluposchain...@googlemail.com>>
> > wrote:
> >
> > I think there are two important
On 09/06/2015 23:26, Johan Tibell wrote:
> Thanks for putting this together.
>
> The proposal says:
>
> "As a consequence, in current Haskell, you can not use Monad-polymorphic
> code safely, because although it claims to work for all Monads, it might
> just crash on you. This kind of implicit no
On 10/06/15 14:22, Johan Tibell wrote:
> On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
> mailto:dluposchain...@googlemail.com>>
> wrote:
>
> I think there are two important consequences of MonadFail. First of
> all, we can
> all safely write failable patterns if we so desire. S
On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky <
dluposchain...@googlemail.com> wrote:
> I think there are two important consequences of MonadFail. First of all,
> we can
> all safely write failable patterns if we so desire. Second, the compiler
> can
> ensure other people's codebases do no
On 2015-06-10 at 00:42:12 +0200, David Luposchainsky wrote:
[...]
> I think there are two important consequences of MonadFail. First of all, we
> can
> all safely write failable patterns if we so desire. Second, the compiler can
> ensure other people's codebases do not lie to us (knowingly or un
I'm a +1 on this proposal as well. In our private Haskell compiler at work, we
have had separate Monad and MonadFail classes since 2010, and it is clearly the
more principled way to handle partiality: make it visible in the inferred
types. I found that there were very few instances when porting
i'll add my token +1 to the land slide
On Tue, Jun 9, 2015 at 11:19 PM, Bardur Arantsson
wrote:
> On 06/09/2015 10:43 PM, David Luposchainsky wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
>
> +1
>
> ___
> Libraries mailing list
> lib
I can give a couple of "rather academic" issues that the status quo causes:
An example of where this has bit us in the hindquarters in the past is that
the old Error class based instance for Monad (Either a) from the mtl
incurred a constraint on the entire Monad instance in order to support
'fail'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10.06.2015 00:26, Johan Tibell wrote:
> "As a consequence, in current Haskell, you can not use Monad-polymorphic code
> safely, because although it claims to work for all Monads, it might just crash
> on you. This kind of implicit non-totality bake
> David Luposchainsky writes:
> the subject says it all. After we successfully put `=>`
> into Monad, it is time to remove something in return: `fail`.
+1
John
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/
Thanks for putting this together.
The proposal says:
"As a consequence, in current Haskell, you can not use Monad-polymorphic
code safely, because although it claims to work for all Monads, it might
just crash on you. This kind of implicit non-totality baked into the class
is terrible."
Is this
+1 from me for both the spirit and the substance of this proposal. We've
been talking about this in the abstract for a while now (since ICFP 2013 or
so) and as concrete plans go, this strikes me as straightforward and
implementable.
-Edward
On Tue, Jun 9, 2015 at 10:43 PM, David Luposchainsky <
d
On 2015-06-09 at 22:43:30 +0200, David Luposchainsky wrote:
[...]
> https://github.com/quchen/articles/blob/master/monad_fail.md
>
> Here's a short abstract:
>
> - Move `fail` from `Monad` into a new class `MonadFail`.
[...]
+1 obviously :-)
___
ghc-d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello *,
the subject says it all. After we successfully put `=>`
into Monad, it is time to remove something in return: `fail`.
Like with the AMP, I wrote up the proposal in Markdown
format on Github, which you can find below as a URL, and in
verbatim
24 matches
Mail list logo