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
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
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,
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
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
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
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:
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
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
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:
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,
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
16 matches
Mail list logo
