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
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,
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
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
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
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:
a
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 ())
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
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 not lie
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
On 10/06/15 14:22, Johan Tibell wrote:
On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
dluposchain...@googlemail.com mailto:dluposchain...@googlemail.com
wrote:
I think there are two important consequences of MonadFail. First of
all, we can
all safely write failable
+1 also improves the correctness of the monad laws
On Jun 10, 2015 7:46 AM, Roman Cheplyaka r...@ro-che.info wrote:
On 10/06/15 14:22, Johan Tibell wrote:
On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
dluposchain...@googlemail.com mailto:dluposchain...@googlemail.com
wrote:
On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka r...@ro-che.info wrote:
On 10/06/15 14:22, Johan Tibell wrote:
On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
dluposchain...@googlemail.com 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
On Wed, Jun 10, 2015 at 2:14 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka r...@ro-che.info wrote:
On 10/06/15 14:22, Johan Tibell wrote:
On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
dluposchain...@googlemail.com
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
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-devs
David Luposchainsky dluposchain...@googlemail.com 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
-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 baked
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
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'.
i'll add my token +1 to the land slide
On Tue, Jun 9, 2015 at 11:19 PM, Bardur Arantsson s...@scientician.net
wrote:
On 06/09/2015 10:43 PM, David Luposchainsky wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1
___
Libraries mailing
23 matches
Mail list logo
