Re: Adding location information to derived code
Please open a ticket for your test case, and (if you can) fix it. The location for the implicit instance should jolly well be the instance declaration for 'instance C Int'! The fix is trivial and I have it on my injectivity branch. I'm really not sure if that problem manifests itself without injectivity. Janek Thanks for spotting this. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan | Stolarek | Sent: 10 June 2015 14:12 | To: ghc-devs@haskell.org | Subject: Adding location information to derived code | | Hi devs, | | say I have: | | class C a where | type F a | type F a = a | | instance C Int | | During compilation of instance C Int GHC will derive a default | associated type instance F Int = | Int. That instance has no location information and so any errors that it | might cause will have a | very uninformative source code location 1:1. I want to fix this but I'm | not sure whether it is a | good idea to add location information to automatically generated code. Do | we make any assumptions | that derived code should have no location information? | | Janek | | --- | Politechnika Łódzka | Lodz University of Technology | | Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. | Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez | pomyłkę | prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. | | This email contains information intended solely for the use of the | individual to whom it is addressed. | If you are not the intended recipient or if you have received this | message in error, | please notify the sender and delete it from your system. | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC build failure
On 2015-06-11 at 16:37:47 +0200, Wolfgang Jeltsch wrote: I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It is a member of the hidden package ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. Use -v to see a list of the files searched for. Any ideas what to do? ...have you ./boot'ed and ./configure'd again (and to be on the safe side, also 'make distclean')? This sounds as if your ghc/ghc-bin.cabal wasn't regenerated from the .in file... ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MonadFail proposal (MFP): Moving fail out of Monad
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, which are unfailable by themselves, but may fail if matching on their fields is done with failable paterns. The part about single-constructor data types is not true. A single-constructor data type has a value ⊥ that is different from applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are two different values. Matching ⊥ against the pattern (_, _) fails, matching (⊥, ⊥) against (_, _) succeeds. So single-constructor data types are not different from all other data types in this respect. The dividing line really runs between data types and newtypes. So only matches against patterns C p where C is a newtype constructor and p is unfailable should be considered unfailable. - Applicative `do` notation is coming sooner or later, `fail` might be useful in this more general scenario. Due to the AMP, it is trivial to change the `MonadFail` superclass to `Applicative` later. (The name will be a bit misleading, but it's a very small price to pay.) I think it would be very misleading having a MonadFail class that might have instances that are not monads, and that this is a price we should not pay. So we should not name the class MonadFail. Maybe, Fail would be a good name. I think we should keep the `Monad` superclass for three main reasons: - We don't want to see `(Monad m, MonadFail m) =` all over the place. But exactly this will happen if we change the superclass of (Monad)Fail from Monad to Applicative. So it might be better to impose a more light-weight constraint in the first place. Functor m might be a good choice. All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC build failure
Maybe you forgot `git submodule init` or `git submodule update`? See this page for a simple trick to never forget again: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias If that didn't work, do a `make maintainer-clean` and try again. On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Hi, I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It is a member of the hidden package ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. Use -v to see a list of the files searched for. Any ideas what to do? All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
GHC build failure
Hi, I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It is a member of the hidden package ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. Use -v to see a list of the files searched for. Any ideas what to do? All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MonadFail proposal (MFP): Moving fail out of Monad
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
f _ = False
Applying f to an expression of the form (x, y) results in True, applying
it to ⊥ results in ⊥. False can never be the result.
That said, it would seem more logical to me if all data types would be
treated equal in monadic pattern matching.
All the best,
Wolfgang
Am Donnerstag, den 11.06.2015, 11:36 -0400 schrieb David Feuer:
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
g9ks1...@acme.softbase.org wrote:
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 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
())
throws an exception, even though the bind is in ErrorT where fail just
returns left:
runErrorT (do { fail oops; return () } :: ErrorT String IO ())
= Left oops
Hope that helps, and hope I understand correctly!
David
On 11 June 2015 at 16:08, Wolfgang Jeltsch g9ks1...@acme.softbase.org
wrote:
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, which are unfailable by
themselves, but may fail if matching on their fields is done with
failable paterns.
The part about single-constructor data types is not true. A
single-constructor data type has a value ⊥ that is different from
applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are two
different values. Matching ⊥ against the pattern (_, _) fails, matching
(⊥, ⊥) against (_, _) succeeds. So single-constructor data types are not
different from all other data types in this respect. The dividing line
really runs between data types and newtypes. So only matches against
patterns C p where C is a newtype constructor and p is unfailable should
be considered unfailable.
- Applicative `do` notation is coming sooner or later, `fail` might
be useful in this more general scenario. Due to the AMP, it is
trivial to change the `MonadFail` superclass to `Applicative`
later. (The name will be a bit misleading, but it's a very small
price to pay.)
I think it would be very misleading having a MonadFail class that might
have instances that are not monads, and that this is a price we should
not pay. So we should not name the class MonadFail. Maybe, Fail would be
a good name.
I think we should keep the `Monad` superclass for three main reasons:
- We don't want to see `(Monad m, MonadFail m) =` all over the place.
But exactly this will happen if we change the superclass of (Monad)Fail
from Monad to Applicative. So it might be better to impose a more
light-weight constraint in the first place. Functor m might be a good
choice.
All the best,
Wolfgang
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
Libraries mailing list
librar...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MonadFail proposal (MFP): Moving fail out of Monad
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 value:
- If the value is of the form con v1 ... vn, sub-patterns are matched
left-to-right against the components of the data value; if all matches
succeed, the overall match succeeds; the first to fail or diverge
causes the overall match to fail or diverge, respectively.
- If the value is of the form con' v1 ... vm, where con is a different
constructor to con', the match fails.
- If the value is ⊥, the match diverges.
In particular, matching (_,_) can only succeed or diverge: failure is
not an option! Desugaring 'do' handles match failure with a catch-all
case that calls 'fail' but doesn't handle ⊥.
On 11 June 2015 at 16:28, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote:
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 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
())
throws an exception, even though the bind is in ErrorT where fail just
returns left:
runErrorT (do { fail oops; return () } :: ErrorT String IO ())
= Left oops
Hope that helps, and hope I understand correctly!
David
On 11 June 2015 at 16:08, Wolfgang Jeltsch g9ks1...@acme.softbase.org
wrote:
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, which are unfailable by
themselves, but may fail if matching on their fields is done with
failable paterns.
The part about single-constructor data types is not true. A
single-constructor data type has a value ⊥ that is different from
applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are two
different values. Matching ⊥ against the pattern (_, _) fails, matching
(⊥, ⊥) against (_, _) succeeds. So single-constructor data types are not
different from all other data types in this respect. The dividing line
really runs between data types and newtypes. So only matches against
patterns C p where C is a newtype constructor and p is unfailable should
be considered unfailable.
- Applicative `do` notation is coming sooner or later, `fail` might
be useful in this more general scenario. Due to the AMP, it is
trivial to change the `MonadFail` superclass to `Applicative`
later. (The name will be a bit misleading, but it's a very small
price to pay.)
I think it would be very misleading having a MonadFail class that might
have instances that are not monads, and that this is a price we should
not pay. So we should not name the class MonadFail. Maybe, Fail would be
a good name.
I think we should keep the `Monad` superclass for three main reasons:
- We don't want to see `(Monad m, MonadFail m) =` all over the place.
But exactly this will happen if we change the superclass of (Monad)Fail
from Monad to Applicative. So it might be better to impose a more
light-weight constraint in the first place. Functor m might be a good
choice.
All the best,
Wolfgang
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MonadFail proposal (MFP): Moving fail out of Monad
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 is the distinction here, (x,y)
is unfailable, but not irrefutable.
And of course, it seems that GHC never actually stopped implementing
unfailable patterns, even though they were removed from the report (or
someone added it back at some point). You just have to know how to observe
this fact.
-- Dan
On Thu, Jun 11, 2015 at 12:11 PM, David Turner
dct25-56...@mythic-beasts.com wrote:
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 value:
- If the value is of the form con v1 ... vn, sub-patterns are matched
left-to-right against the components of the data value; if all matches
succeed, the overall match succeeds; the first to fail or diverge
causes the overall match to fail or diverge, respectively.
- If the value is of the form con' v1 ... vm, where con is a different
constructor to con', the match fails.
- If the value is ⊥, the match diverges.
In particular, matching (_,_) can only succeed or diverge: failure is
not an option! Desugaring 'do' handles match failure with a catch-all
case that calls 'fail' but doesn't handle ⊥.
On 11 June 2015 at 16:28, Wolfgang Jeltsch g9ks1...@acme.softbase.org
wrote:
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 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 ())
throws an exception, even though the bind is in ErrorT where fail just
returns left:
runErrorT (do { fail oops; return () } :: ErrorT String IO ())
= Left oops
Hope that helps, and hope I understand correctly!
David
On 11 June 2015 at 16:08, Wolfgang Jeltsch g9ks1...@acme.softbase.org
wrote:
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, which are unfailable by
themselves, but may fail if matching on their fields is done with
failable paterns.
The part about single-constructor data types is not true. A
single-constructor data type has a value ⊥ that is different from
applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are
two
different values. Matching ⊥ against the pattern (_, _) fails,
matching
(⊥, ⊥) against (_, _) succeeds. So single-constructor data types are
not
different from all other data types in this respect. The dividing line
really runs between data types and newtypes. So only matches against
patterns C p where C is a newtype constructor and p is unfailable
should
be considered unfailable.
- Applicative `do` notation is coming sooner or later, `fail` might
be useful in this more general scenario. Due to the AMP, it is
trivial to change the `MonadFail` superclass to `Applicative`
later. (The name will be a bit misleading, but it's a very small
price to pay.)
I think it would be very misleading having a MonadFail class that
might
have instances that are not monads, and that this is a price we should
not pay. So we should not name the class MonadFail. Maybe, Fail would
be
a good name.
I think we should keep the `Monad` superclass for three main reasons:
- We don't want to see `(Monad m, MonadFail m) =` all over the
place.
But exactly this will happen if we change the superclass of
(Monad)Fail
from Monad to Applicative. So it might be better to impose a more
light-weight constraint in the first place. Functor m might be a good
choice.
All the best,
Wolfgang
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
RE: GHC build failure
I got the same thing on my 7.10 branch. But when I said sh validate (which starts with make distclean etc) all was well. S | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Wolfgang Jeltsch | Sent: 11 June 2015 16:20 | To: ghc-devs@haskell.org | Subject: Re: GHC build failure | | Hi again, | | it still fails with the same error message. | | All the best, | Wolfgang | | Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch: | Hi, | | I did not care about the submodules; so this could be the reason of | the failure. That said, running | | git submodule update --init | | now only showed a message regarding utils/haddock, which causes me | some doubts that it will really fix the issue with deepseq. Let’s | see. | | All the best, | Wolfgang | | Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema: |Maybe you forgot `git submodule init` or `git submodule update`? | See |this page for a simple trick to never forget again: | | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodu |les#UsingaGitalias | | |If that didn't work, do a `make maintainer-clean` and try again. | | | |On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch |g9ks1...@acme.softbase.org wrote: |Hi, | |I just updated my GHC HEAD copy via git pull and tried to |rebuild GHC |with BuildFlavour set to devel2. I got the following error |message: | |ghc/InteractiveUI.hs:68:8: error: |Could not find module ‘Control.DeepSeq’ |It is a member of the hidden package |‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. |Use -v to see a list of the files searched for. | |Any ideas what to do? | |All the best, |Wolfgang | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC build failure
OK, so I think the reason is because this commit:
https://phabricator.haskell.org/rGHC3b55659d4f54e503f4e550d762bc55a2650ed13d
actually changed the ghc-bin.cabal.in file under ghc/. Which we use to
generate ghc-bin.cabal, which is actually fed to Cabal to build the
'ghc' executable. The build system generates these files from .in
files (from autoconf) very early so 'make' doesn't track the
dependencies here, and it can't rebuild the files from the .in files.
That means you need to regenerate the .cabal file from the .in file to
pick up 'deepseq', which was added to Build-Depends.
The reason this gets 'fixed' with ./validate is precisely because
validate cleans the entire tree and re-boots it before continuing. So
it happens automatically.
TL;DR you should re-./boot and re-./configure again, as Herbert said.
In practice this shouldn't cost you much time, because even though GHC
will re-run the build steps, most of the results of those steps will
be cached compilations, which it can skip. If that doesn't work, then
distclean and start over - which sucks, but you won't have to do it
again ('make' will work fine to rebuilt).
On Thu, Jun 11, 2015 at 11:23 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
I got the same thing on my 7.10 branch. But when I said sh validate (which
starts with make distclean etc) all was well.
S
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Wolfgang Jeltsch
| Sent: 11 June 2015 16:20
| To: ghc-devs@haskell.org
| Subject: Re: GHC build failure
|
| Hi again,
|
| it still fails with the same error message.
|
| All the best,
| Wolfgang
|
| Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch:
| Hi,
|
| I did not care about the submodules; so this could be the reason of
| the failure. That said, running
|
| git submodule update --init
|
| now only showed a message regarding utils/haddock, which causes me
| some doubts that it will really fix the issue with deepseq. Let’s
| see.
|
| All the best,
| Wolfgang
|
| Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema:
|Maybe you forgot `git submodule init` or `git submodule update`?
| See
|this page for a simple trick to never forget again:
|
| https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodu
|les#UsingaGitalias
|
|
|If that didn't work, do a `make maintainer-clean` and try again.
|
|
|
|On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch
|g9ks1...@acme.softbase.org wrote:
|Hi,
|
|I just updated my GHC HEAD copy via git pull and tried to
|rebuild GHC
|with BuildFlavour set to devel2. I got the following error
|message:
|
|ghc/InteractiveUI.hs:68:8: error:
|Could not find module ‘Control.DeepSeq’
|It is a member of the hidden package
|‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’.
|Use -v to see a list of the files searched for.
|
|Any ideas what to do?
|
|All the best,
|Wolfgang
|
|
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
|
|
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Regards,
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MonadFail proposal (MFP): Moving fail out of Monad
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 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 ())
throws an exception, even though the bind is in ErrorT where fail just
returns left:
runErrorT (do { fail oops; return () } :: ErrorT String IO ())
= Left oops
Hope that helps, and hope I understand correctly!
David
On 11 June 2015 at 16:08, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote:
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, which are unfailable by
themselves, but may fail if matching on their fields is done with
failable paterns.
The part about single-constructor data types is not true. A
single-constructor data type has a value ⊥ that is different from
applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are two
different values. Matching ⊥ against the pattern (_, _) fails, matching
(⊥, ⊥) against (_, _) succeeds. So single-constructor data types are not
different from all other data types in this respect. The dividing line
really runs between data types and newtypes. So only matches against
patterns C p where C is a newtype constructor and p is unfailable should
be considered unfailable.
- Applicative `do` notation is coming sooner or later, `fail` might
be useful in this more general scenario. Due to the AMP, it is
trivial to change the `MonadFail` superclass to `Applicative`
later. (The name will be a bit misleading, but it's a very small
price to pay.)
I think it would be very misleading having a MonadFail class that might
have instances that are not monads, and that this is a price we should
not pay. So we should not name the class MonadFail. Maybe, Fail would be
a good name.
I think we should keep the `Monad` superclass for three main reasons:
- We don't want to see `(Monad m, MonadFail m) =` all over the place.
But exactly this will happen if we change the superclass of (Monad)Fail
from Monad to Applicative. So it might be better to impose a more
light-weight constraint in the first place. Functor m might be a good
choice.
All the best,
Wolfgang
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MonadFail proposal (MFP): Moving fail out of Monad
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 ())
throws an exception, even though the bind is in ErrorT where fail just
returns left:
runErrorT (do { fail oops; return () } :: ErrorT String IO ())
= Left oops
Hope that helps, and hope I understand correctly!
David
On 11 June 2015 at 16:08, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote:
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, which are unfailable by
themselves, but may fail if matching on their fields is done with
failable paterns.
The part about single-constructor data types is not true. A
single-constructor data type has a value ⊥ that is different from
applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are two
different values. Matching ⊥ against the pattern (_, _) fails, matching
(⊥, ⊥) against (_, _) succeeds. So single-constructor data types are not
different from all other data types in this respect. The dividing line
really runs between data types and newtypes. So only matches against
patterns C p where C is a newtype constructor and p is unfailable should
be considered unfailable.
- Applicative `do` notation is coming sooner or later, `fail` might
be useful in this more general scenario. Due to the AMP, it is
trivial to change the `MonadFail` superclass to `Applicative`
later. (The name will be a bit misleading, but it's a very small
price to pay.)
I think it would be very misleading having a MonadFail class that might
have instances that are not monads, and that this is a price we should
not pay. So we should not name the class MonadFail. Maybe, Fail would be
a good name.
I think we should keep the `Monad` superclass for three main reasons:
- We don't want to see `(Monad m, MonadFail m) =` all over the place.
But exactly this will happen if we change the superclass of (Monad)Fail
from Monad to Applicative. So it might be better to impose a more
light-weight constraint in the first place. Functor m might be a good
choice.
All the best,
Wolfgang
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MonadFail proposal (MFP): Moving fail out of Monad
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
g9ks1...@acme.softbase.org wrote:
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 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
())
throws an exception, even though the bind is in ErrorT where fail just
returns left:
runErrorT (do { fail oops; return () } :: ErrorT String IO ())
= Left oops
Hope that helps, and hope I understand correctly!
David
On 11 June 2015 at 16:08, Wolfgang Jeltsch g9ks1...@acme.softbase.org
wrote:
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, which are unfailable by
themselves, but may fail if matching on their fields is done with
failable paterns.
The part about single-constructor data types is not true. A
single-constructor data type has a value ⊥ that is different from
applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are two
different values. Matching ⊥ against the pattern (_, _) fails, matching
(⊥, ⊥) against (_, _) succeeds. So single-constructor data types are not
different from all other data types in this respect. The dividing line
really runs between data types and newtypes. So only matches against
patterns C p where C is a newtype constructor and p is unfailable should
be considered unfailable.
- Applicative `do` notation is coming sooner or later, `fail` might
be useful in this more general scenario. Due to the AMP, it is
trivial to change the `MonadFail` superclass to `Applicative`
later. (The name will be a bit misleading, but it's a very small
price to pay.)
I think it would be very misleading having a MonadFail class that might
have instances that are not monads, and that this is a price we should
not pay. So we should not name the class MonadFail. Maybe, Fail would be
a good name.
I think we should keep the `Monad` superclass for three main reasons:
- We don't want to see `(Monad m, MonadFail m) =` all over the place.
But exactly this will happen if we change the superclass of (Monad)Fail
from Monad to Applicative. So it might be better to impose a more
light-weight constraint in the first place. Functor m might be a good
choice.
All the best,
Wolfgang
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
Libraries mailing list
librar...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC build failure
Am Donnerstag, den 11.06.2015, 16:50 +0200 schrieb Herbert Valerio Riedel: On 2015-06-11 at 16:37:47 +0200, Wolfgang Jeltsch wrote: I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It is a member of the hidden package ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. Use -v to see a list of the files searched for. Any ideas what to do? ...have you ./boot'ed and ./configure'd again (and to be on the safe side, also 'make distclean')? This sounds as if your ghc/ghc-bin.cabal wasn't regenerated from the .in file... The page at https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking says that just running make again is enough. Also, I do not want to run make distclean, of course, since I want the rebuild to be fast. All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC build failure
Hi, I did not care about the submodules; so this could be the reason of the failure. That said, running git submodule update --init now only showed a message regarding utils/haddock, which causes me some doubts that it will really fix the issue with deepseq. Let’s see. All the best, Wolfgang Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema: Maybe you forgot `git submodule init` or `git submodule update`? See this page for a simple trick to never forget again: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias If that didn't work, do a `make maintainer-clean` and try again. On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Hi, I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It is a member of the hidden package ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. Use -v to see a list of the files searched for. Any ideas what to do? All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC build failure
Hi again, it still fails with the same error message. All the best, Wolfgang Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch: Hi, I did not care about the submodules; so this could be the reason of the failure. That said, running git submodule update --init now only showed a message regarding utils/haddock, which causes me some doubts that it will really fix the issue with deepseq. Let’s see. All the best, Wolfgang Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema: Maybe you forgot `git submodule init` or `git submodule update`? See this page for a simple trick to never forget again: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias If that didn't work, do a `make maintainer-clean` and try again. On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Hi, I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It is a member of the hidden package ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. Use -v to see a list of the files searched for. Any ideas what to do? All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
