GHC's pattern-match overlap checker is a regular source of (justified)
complaints. Somehow it never gets to the top of our agenda.
It's a well-identified piece of the compiler if anyone feels motivated
to lend a hand. Otherwise I can't promise when we'll get to it.
But keep prodding us at
Peter,
This is a most excellent bug. Thank you. It turns out to be an
obscure interaction in the context-simplication machinery between
functional dependencies and superclasses.
I need to think about how to fix it, and I'm buried in reviewing right
now, so I hope you are not utterly stuck.
That's a bug; I'll fix it.
| -Original Message-
| From: Ross Paterson [mailto:[EMAIL PROTECTED]]
| Sent: 22 April 2002 14:15
| To: [EMAIL PROTECTED]
| Subject: Re: scoped type variables in instance?
|
|
| OK, I see this was intentional:
|
| The type variables in the head of a
It's a bug all right. The definition of A should be rejected.
It's not legal H98
Will fix. Thanks for the report
Simon
| -Original Message-
| From: Jorge Adriano [mailto:[EMAIL PROTECTED]]
| Sent: 17 April 2002 18:26
| To: [EMAIL PROTECTED]
| Subject: Bugs?
|
|
| I've sent this
| Is rejecting Haskell 98 modules when -fglasgow-exts is on
| also a bug? (i.e. does GHC Haskell aim to be a conservative
| extension of H98?)
Yes, we do so aim, but this seems to be an occasion where
there's no obvious way to make the extension 100% conservative
without making the extended
Well, it says it's unsafe!
The point is that
(1::Int) `unsafePtrEq` (1::Int)
is not necessarily True. The 1 is boxed, and the interpreter
chooses to allocate two boxes while the compiler decides to just
share one. Even with the compiler, when it computes a new
Int it allocates it in a
Title: Message
Yes, I
fixed this a week or two ago. You need to 'cvs update'.
The
cvs commit logs should show which commit fixed it if you
want
to
just grab the patch.
Simon
-Original Message-From: Mike Thomas
[mailto:[EMAIL PROTECTED]] Sent: 12 May 2002 10:29To:
Title: Message
maybe
you need to rebuild the compiler you are compiling *with*?
-Original Message-From: Mike Thomas
[mailto:[EMAIL PROTECTED]] Sent: 13 May 2002 22:19To:
Simon Peyton-Jones; [EMAIL PROTECTED]Subject: Re:
stgSyn/CoreToStg.lhs:1112: Couldn't match
GHC's notion of unused is broken in ways that are not trivial
to fix. It's been on my wish list for ages...but it's not a very
exciting problem to tackle.
Simon
| -Original Message-
| From: Feliks Kluzniak [mailto:[EMAIL PROTECTED]]
| Sent: 15 May 2002 19:31
| To: [EMAIL PROTECTED]
|
Try -funfolding-use-threshold
A rather poor user interface I fear.
Simon
| -Original Message-
| From: Kirsten Chevalier [mailto:[EMAIL PROTECTED]]
| Sent: 20 May 2002 02:35
| To: [EMAIL PROTECTED]
| Subject: -funfolding-use-threshold in GHC 5.03
|
|
| I'm using a copy of GHC
Amazingly, the external-core parser was parsing recursive
groups with only one binding as non-recursive.
Fixed now (in CVS)
Simon
| -Original Message-
| From: Kirsten Chevalier [mailto:[EMAIL PROTECTED]]
| Sent: 20 May 2002 03:01
| To: [EMAIL PROTECTED]
| Subject: Bug in external Core
But it's easy to fix too, so good for a Friday morning. Done
S
| -Original Message-
| From: Okasaki, C. DR EECS [mailto:[EMAIL PROTECTED]]
| Sent: 23 May 2002 18:46
| To: '[EMAIL PROTECTED]'
| Subject: amusing but very minor bug
|
|
| I've recently been playing with functions with
Strange. You fix definitely isn't the Right Thing, but there's clearly
something wrong going on.
Can you give more details please? I.e. give source code and
what commands you executed to show up the bug?
Thanks
Simon
| -Original Message-
| From: Kirsten Chevalier [mailto:[EMAIL
Aha. Try now. I think I've fixed it.
Simon
| -Original Message-
| From: Kirsten Chevalier [mailto:[EMAIL PROTECTED]]
| Sent: 24 May 2002 12:00
| To: Simon Peyton-Jones
| Cc: GHC bugs (GHC bugs)
| Subject: Re: Bug in CorePrep.lhs
|
|
| On Fri, May 24, 2002 at 03:33:45AM -0700, Simon
Title: Message
OK,
this is a bad feature of the new binary-interface story:
if
there is an old Foo.hi file around with the wrong format, it
can
crash the compiler. We need to add a magic-number to
the
front or something.
Meanwhile, delete all your .hi files you'll be fine.
Simon
Title: Message
I
doubt it.
Simon
-Original Message-From: Mike Thomas
[mailto:[EMAIL PROTECTED]] Sent: 29 June 2002 10:32To:
Simon Peyton-Jones; [EMAIL PROTECTED]Cc:
[EMAIL PROTECTED]Subject: Re: GHC 5.03 CVS NT2000 Mingw32 - Possible
profiling problem in rts/GC.c
Aha. You have a \ in your rule name. That doesn't work in
5.02 for tiresome reasons; it's ok in 5.04
thanks for the clear report
Simon
| -Original Message-
| From: Arjan van IJzendoorn [mailto:[EMAIL PROTECTED]]
| Sent: 27 June 2002 15:46
| To: [EMAIL PROTECTED]
| Subject: The
Thanks. Will be fixed in 5.04
| -Original Message-
| From: Christian Maeder [mailto:[EMAIL PROTECTED]]
| Sent: 04 July 2002 13:37
| To: [EMAIL PROTECTED]
| Subject: typo in error message: duplicate the
|
|
| The following error message just contains a typo before
| existential
The thing to do is to use ghc as your C compiler.
It will entirely ingore your path etc, and will faithfully
use the mingw stuff, give the compiler the right flags etc.
Perhaps this possibility is not stated clearly enough in the manual;
I see that Sigbjorn committed a note about it yesterday in
| data Test = Test { field :: Int } deriving (Eq,Show,Read)
| main = print (Test {field=(-1)})
|
| in ghc-5.02.2:
| Test{field=(-1)}
|
| in ghc-5.04:
| Test {field=-1}
Ah yes, and that lexes wrong: the =- is one lexeme. Solution: put
spaces round the '=' sign. Will be fixed!
Please say which version of GHC you are using.
This program works fine with GHC 5.02.2
Simon
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 22 August 2002 20:47
| To: [EMAIL PROTECTED]
| Subject: bug with rank n polymorphism in classes
|
|
| consider:
Good point. Fixed, and will be in 5.04.1
Thanks for reporting this.
Simon
| -Original Message-
| From: Oliver Braun [mailto:[EMAIL PROTECTED]]
| Sent: 23 August 2002 11:59
| To: [EMAIL PROTECTED]
| Subject: (fwd) FranTk with ghc-5.04
|
|
| Hi Meurig,
|
| I am currently working on
This is the same problem as was causing GHC 5.04 to go into
a loop on FranTk. It's now fixed in the repository and the fix
will be in 5.04.1. Meanwhile use 5.02!
Thanks for the report
Simon
| -Original Message-
| From: Nobuo Yamashita [mailto:[EMAIL PROTECTED]]
| Sent: 16 August
I spoke too soon. This is a real bug, and I'm fixing it.
Thanks for the report
S
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 01 September 2002 14:27
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: RE: bug with rank n polymorphism
Thanks for the report. It's a known bug in 5.04, will be fixed in
5.04.1 (which is imminent)
Simon
| -Original Message-
| From: Mark Tullsen [mailto:[EMAIL PROTECTED]]
| Sent: 10 September 2002 19:47
| To: [EMAIL PROTECTED]
| Subject: infinite loop in ghc5.04
|
| When I attempt to
Yes, thanks. This is a known bug in 5.04.
What is interesting to me is how many people are using self-recursive
newtypes, with no intervening data types. That is, a type that would be
infinite if the newtype were a type synonym. At least four people have
independently reported the bug, so
| The report says The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F.
|
| It unclear to me why there needs to be this provision for records with
| The report says The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F.
|
| It unclear to me why there needs to be this provision for records with
| I think the sentence in question (end of 3.15.2) is just a
clarification;
| the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3}
are
| all illegal because they omit a value for a strict field. That is,
it's
| correct, though not strictly necessary, nor does it cover all the
I allege that I have fixed this. You now get type checking of external
core without saying -dcore-lint.
Kirsten, would you care to say how you are using External Core?
Simon
| -Original Message-
| From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]]
| Sent: 05 September 2002 21:05
| To:
| There is a typechecker for Ext Core already, in
| fptools/ghc/utils/ext-core. It would probably take some work to adapt
it
| to be used with GHC, and to change it so it doesn't have the module
names and
| primitives from GHC 4.08 wired into it, but would adapting it be the
right
| thing to do?
[EMAIL PROTECTED] would be a better bet.
Wolfgang Thaller is Supreme Being for MacOS so I'm cc'ing him too.
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: 14 October 2002 14:44
| To: [EMAIL PROTECTED]
| Subject: ghc MacOS X 10.2 behaviour
|
| Hi all,
Good idea, Alastair. I'll do it.
Simon
| -Original Message-
| From: Alastair Reid [mailto:[EMAIL PROTECTED]]
| Sent: 08 October 2002 12:44
| To: [EMAIL PROTECTED]
| Subject: implicit parameter bindings in do notation
|
|
| Using
|
| do
| let ?x=...
| ...
|
| doesn't seem
OK, I've implemented this in the HEAD. Thanks for the suggestion,
Alastair.
Simon
| -Original Message-
| From: Alastair Reid [mailto:alastair;reid-consulting-uk.ltd.uk]
| Sent: 08 October 2002 12:44
| To: [EMAIL PROTECTED]
| Subject: implicit parameter bindings in do notation
|
|
|
Sigbjorn (and others interested in Win32 I/O behaviour)
The fact that MS CRT differs from Unix doesn't mean that the Haskell
interface should necessarily differ. The Haskell impl of
doesDirectoryExist could, on Win32, trim off trailing '/' or '\', in
order to make the behaviour consistent.
| That would take care of the incompatibility here, but
| it's a slippery slope.
| Should Haskell provide you with
| a platform-independent view of filenames and file
| systems?
|
| I think that if a language implementation takes the trouble to provide
a
| cross-platform library function
| In GHC 5.04.1, derived instances of Show mishandle precedence:
|
| Prelude putStrLn (showsPrec 10 (Just 0) )
| Just 0
|
| The result should be: (Just 0)
I think it's a bug in the Report, not in GHC, actually. The Report says
(Section D.4)
The function 'showsPrec d x r' accepts a
Excellent bug thank you. Fixed in the repository.
Simon
| -Original Message-
| From: Andrew J Bromage [mailto:ajb;spamcop.net]
| Sent: 30 October 2002 00:45
| To: [EMAIL PROTECTED]
| Subject: Compiler panic
|
| G'day all.
|
| On a very recently checked out copy of GHC (late last week,
| What I don't understand, however, is why adding that extra
| constraint helps in any way? Shouldn't the addition of new
| things in the context only make more options available? Why
| does it make some of the existing, amgibuous options go away?
With the extra constraint, the instance decl can
| Yes, but isn't that an implementation problem surfacing at the
| language level? All the dictionaries needed to delay the decision to
| the point of use could also be made available when compiling the
| original program, no? After all, that's the reason why there's an
| ambiguity in the first
No, -fglasgow-exts nukes some valid H98 programs. Reason: the
extensions need to take up some extra syntax. For example, 'forall' is
a keyword in -fglasgow-exts but not in H98.
In your case it thinks you are write an unboxed tuple
(# foo, baz #)
Simon
| -Original Message-
|
It's very hard to synchronise all the packages people might want, test
them, and to bundle them into GHC distributions. Instead we encourage
package-writers to distribute their package themselves, which is what
Krasimir has done:
http://haskell.cs.yale.edu/ObjectIO/
We plan to provide links
Ah, indeed so. Thank you for reporting this. It turned out to be
caused by a function written like this
f (C a) = ...
f (D a b) = ...
f other = False
The data type changed, and we should have added a new case to the
function, but the default case caught it, so there was
The reason there's an error message at all is because of the
monomorphism restriction. So that's not surprising.
So the compiler has to solve the constraints { Num (f a), Functor f }
in the absence of any other context whatsoever.
So the constraint (Functor f) is certainly ambiguous, in the
|Prelude.LT :: Prelude.Ordering = Prelude.zdwLT;
|Prelude.GT :: Prelude.Ordering = Prelude.zdwGT;
|Prelude.EQ :: Prelude.Ordering = Prelude.zdwEQ;
|
| Except these last three lines are backwards. They should read:
|
|Prelude.zdwLT :: Prelude.Ordering = Prelude.LT;
Not so, in
Your wish is my command
| The reason there's an error message at all is because of the
| monomorphism restriction. So that's not surprising.
| Can you suggest a better error message? I'm always looking for ways
to
| report errors more informatively.
|
| It may be hard to do, but it would
Good point. It'll fail more gracefully from now on.
The solution (necessary even after the fix) is to put a space after the
'$',
so you don't have $foo, just $ foo.
Reason: $foo means something special for Template Haskell.
Simon
| -Original Message-
| From: Nicolas.Oury
Fixed now, thank you.
Simon
| -Original Message-
| From: Kirsten Chevalier [mailto:[EMAIL PROTECTED]]
| Sent: 09 December 2002 02:01
| To: [EMAIL PROTECTED]
| Subject: Core Lint bug
|
| The attached program, chr.hs, causes GHC to generate external Core
that
| results in a type error
It's not spurious. Both
M.sort
and
Data.List.sort
are in scope under both names:
sort and M.sort
And that makes it ambiguous according to the spec.
Simon
| -Original Message-
| From: Ross Paterson [mailto:[EMAIL PROTECTED]]
| Sent: 06 January 2003 12:01
| To:
| That would be the analysis if the export list were (module M), but
| If the export list is omitted, all values, types and classes defined
| in the module are exported, _but not those that are imported_.
| There should never be ambiguity or conflicts if the export list is
| omitted.
Stupid me.
Three problems here
1. Your program is ill-staged. Running the splice requires executing
'foo',
so 'foo' must be in another module.
2. GHC should report that as a staging error, but wasn't.
3. But even then it should not have crashed. Its should have reported
a linking error when trying to
Yes, this is a bug (GHC is failing to output some important implicit
definitions). It's fixed in the HEAD, so you can use that (if you build
it from source). I'm not quite sure when it got fixed.
Simon
| -Original Message-
| From: Tobias Gedell [mailto:[EMAIL PROTECTED]]
| Sent: 20
Because GHC does not allow you to instantiate a polymorphic type
variable with a polymorphic type. For example, you can have
Maybe Int
Maybe (Int - Int)
but not
Maybe (forall a. a-a)
The Maybe type is defined thus
data Maybe b = Nothing | Just b
so the type
Curious. Doesn't happen here. We're unlikely to fix this unless
someone knows what is going on and can tell us...
Simon
| -Original Message-
| From: Dean Herington [mailto:[EMAIL PROTECTED]]
| Sent: 22 January 2003 19:26
| To: [EMAIL PROTECTED]
| Subject: funny bold ouput in GHCI
|
|
| The first version doesn't compile - the error is:
| Type synonym `F3' should have 1 argument, but has been given 0
| In the type: Pair F3 F2
| While checking the type signature for `p'
Type synonyms in Haskell must be saturated (i.e. given all their
argments).
GHC lifts this restriction
Thanks. Should be rejected, because MonadState takes two type
parameters, and
the deriving stuff only allows one. You might be able to say
...deriving(MonadState m)
or some such
I'll fix up the compiler to reject it more gracefully
Simon
| -Original Message-
| From: Dean
Excellent point. Now fixed in the HEAD. Thanks for the report.
Simon
| -Original Message-
| From: Tobias Gedell [mailto:[EMAIL PROTECTED]]
| Sent: 22 January 2003 16:56
| To: glasgow-haskell-bugs
| Subject: Invalid binding names in generated Core code
|
| The generation of binding
| The attached file (generated by running ghc -fext-core on the Fibheaps
| benchmark from the nofib suite) fails to typecheck:
|
| $ ghc -dcore-lint Fibheaps.hcr
|
| Couldn't match `#' against `*'
| Expected kind: #
| Inferred kind: *
| When checking kinds in `GHC.Prim.(-)
| I have found what causes the bug and implemented a possibly
| fix for it.
| The problem has to do with source types that aren't expanded before
| tidying them.
Quite right. Well found.
| I believe that there are three possible fixes:
|
| 1. Make sure that all type variables that are
| Are Unit and Z0T considered equal?
No, the are not. Z0T is the zero-tuple type ()
Unit is used only in generic programming, and can be written 1 (in
types)
| In GHC/Base.hcr they are both defined:
|
| -
|%data GHCziBase.Unit =
| {GHCziBase.Unit};
|%data GHCziBase.Z0T =
|
Thanks for the report. I'm not 100% certain why it happens in 5.04.2,
but it doesn't happen in the HEAD. The error message is still not
great, but at least it's not gibberish.
Simon
Data.hs:288:
Could not deduce (ReprType r t) from the context ()
arising from use of `getter'' at
The desugarer generates tuples when desugaring mutually-recursive
functions, and I bet that is what is causing the problem.
These optimiser usually gets rid of them, as you found.
It's a known shortcoming which has never gotten high enough up the list
to solve.
Could you please keep the source
I've made this fix in the HEAD, thank you.
Simon
| -Original Message-
| From: Tobias Gedell [mailto:[EMAIL PROTECTED]]
| Sent: 25 January 2003 11:54
| To: glasgow-haskell-bugs
| Subject: Core, implicit bindings are emitted in the wrong order
|
| The implicit bindings are emitted in the
Right; I've committed this change.
SImon
| -Original Message-
| From: Tobias Gedell [mailto:[EMAIL PROTECTED]]
| Sent: 29 January 2003 18:08
| To: glasgow-haskell-bugs
| Subject: Core, shadowing type variable names, possible fix
|
| I have found what causes the bug and implemented a
Good point. Error message improved, regression test added.
Thanks for the suggestion
Simon
| -Original Message-
| From: Dean Herington [mailto:[EMAIL PROTECTED]]
| Sent: 05 February 2003 19:14
| To: [EMAIL PROTECTED]
| Subject: confusing error message
|
| buzzard(118)% cat Bug5.hs
|
Urk! Good point!
Yes, please do commit those changes. Do you have commit permission now?
Simon
| -Original Message-
| From: Tobias Gedell [mailto:[EMAIL PROTECTED]]
| Sent: 06 February 2003 13:14
| To: glasgow-haskell-bugs
| Subject: The boot interface files for TypeRep contain errors
I've fixed this one, I believe.
Simon
| -Original Message-
| From: Kirsten Chevalier [mailto:[EMAIL PROTECTED]]
| Sent: 07 January 2003 20:27
| To: [EMAIL PROTECTED]
| Subject: External Core parser bug
|
| The attached file was generated by running 'ghc -fext-core' on the
Atom
|
Thanks; fixed.
Simon
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 04 February 2003 23:47
| To: [EMAIL PROTECTED]
| Subject: badness with -fmax-simplifier-iterations
|
| A few things. First of all, if you're stupid and say:
|
| ghc ...
| This bug is older! ghc 5.04 does not enforce that the return type of
| main
| is (). In fact with 5.04 you can return anything you want and get
very
| fancy exception on termination if you return a more complex data
type.
|
| I don't know about an exception on termination (Is it a known
This has gone away with my new constructor-naming commit.
Simon
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 28 November 2002 15:38
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: RE: new -fext-core bug (X = zdwX)
|
| Okay, my bad
This is ok in ghc-5.04.2 onwards. Time to update your GHC
Simon
| -Original Message-
| From: Jorge Adriano [mailto:[EMAIL PROTECTED]]
| Sent: 13 February 2003 14:21
| To: [EMAIL PROTECTED]; GHC Users Mailing List
| Subject: Pattern matching with implicit par. bug
|
| There it goes,
|
| -Original Message-
| From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]]
| Sent: 14 February 2003 15:25
| To: Simon Peyton-Jones
| Subject: Fw: ghc crashes
|
| I haven't had the time to look at this one..perhaps it will crash
| similarly on non-win32 boxes too?
|
| --sigbjorn
|
| - Original Message
Excellent bug thank you. Now fixed.
Simon
| -Original Message-
| From: Johannes Waldmann [mailto:[EMAIL PROTECTED]]
| Sent: 18 February 2003 11:24
| To: [EMAIL PROTECTED]
| Subject: ghc-5.04.2: panic! (the `impossible' happened, GHC version
5.04.2):
|
| class Foo a where foo :: a - ()
I don't think this had much to do with profiling actually. It was just
a bug!
Fixed now.
Simon
| -Original Message-
| From: Kirsten Chevalier [mailto:[EMAIL PROTECTED]]
| Sent: 14 February 2003 01:10
| To: [EMAIL PROTECTED]
| Subject: Profiling and ext-core
|
| The latest version of
Thanks. I've fixed this bug.
| -Original Message-
| From: Volodimir Rudenko [mailto:[EMAIL PROTECTED]]
| Sent: 19 February 2003 16:47
| To: [EMAIL PROTECTED]
| Subject: broken :info
|
| The :info command is broken in the current GHCi (built from CVS HEAD,
| Feb 18, on RedHat Linux 8.0).
Aha, this was more complicated. The trouble is that an External Core
module may refer to some implicit things (in this case the type :TEq)
that are automatically produced from a normal Haskell thing (in this
case the class Eq). The dependency analyser wasn't seeing these
implicit dependencies,
http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/bugs.html
Regrettable, but documented.
Simon
| -Original Message-
| From: Jon Fairbairn [mailto:[EMAIL PROTECTED]
| Sent: 03 March 2003 11:40
| To: GHC bugs
| Subject: loop?
|
| The following module takes an inordinately long
| Thanks, that was quick. Have updated my libraries tree, but
| don't build ghc from source (no space left here..). How do I
| build libraries/network with my installed ghc-5.04 (?? have
| there been any socket-relevant fixes since then, checking
| with 5.04.2 [which resets my filetype settings
Yes, please do so; thank you. It's very very dodgy to do so, so even if
it's not rejected, it probably should be.
Simon
| -Original Message-
| From: Volker Stolz [mailto:[EMAIL PROTECTED]
| Sent: 10 March 2003 14:40
| To: [EMAIL PROTECTED]
| Subject: (Deriving) instances in .hi-boot not
Yes, this is a known bug, but thank you for reporting it anyway. I'm
going to fix it as part of my next sweep though.
I enclose a message that gives a workaround.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Ch. A. Herrmann
| Sent: 05
| GHC doesn't try to hash-cons types, because it usually doesn't
matter,
| but I bet it does here.
|
| Would this be a major rewrite? [As an aside, a similiar problem showed
up
| when generating conversion functions for generic representation
types.]
I really don't know. Hash-consing is
I'm not sure it's the type inference so much as the type abstractions
and applications. But yes, your point is a good one
S
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Simon Marlow
| Sent: 28 May 2003 18:03
| To: Simon Peyton-Jones; Ralf Hinze
Good point. Fixed in the head, but not in 6.0
Thanks
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Ralf Hinze
| Sent: 28 May 2003 20:40
| To: GHC bugs
| Subject: n + k patterns
|
| GHCi infers for
|
| fac 0 = 1
| For some reason, even though only getCharacterName is exported, when
| optimisation is switched on, the interface file balloons a
thousandfold:
|
| $ ls -l UnicodeNames.*hi
| -rw-r--r--1 ashley ashley5854480 May 28 02:49
UnicodeNames.hi
| -rw-r--r--1 ashley ashley5854497 May
I believe I've fixed this one.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Simon Marlow
| Sent: 04 June 2003 11:00
| To: George Russell; [EMAIL PROTECTED]
| Subject: RE: ghc --make and missing interface files
|
|
| Hello all, I have a
| So, the fold/build rule is being applied even if you run GHC with
| -fno-foldr-build-on. I RTFSed, and it appears that the only place in
GHC
| where the -ffoldr-build-on command-line option is looked at is in
| DsListComp.lhs.
|
| In the flag reference in the manual, the effect of
Yes, that's right. The Template Haskell implementation in GHC 6.0 is has
one or two big holes; in ptic
- you can only reify type declarations
- type splices are not there
Tim and I are working on a new iteration of the design which we'll put
out to the Template Haskell mailing
Check out:
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2003-June/003330.h
tml
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of [EMAIL PROTECTED]
| Sent: 29 June 2003 11:17
| To: [EMAIL PROTECTED]
| Subject: ghc-6.0 on win32 panic
|
Fixed thank you.
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Hal Daume
| Sent: 30 June 2003 18:09
| To: [EMAIL PROTECTED]
| Subject: small bug with :info and ids beginning with _
|
| :info treats _a as an infix operator in ghci.
|
| Prelude
| Main mirror []
| ERROR - Cannot find show function for:
| *** Expression : mirror []
| *** Of type: [a]
|
| Instructor:
| it's because `mirror []' has the polymorphic type `[a]' and the
| compiler cannot determine the `Show' instance for `a'.
|
| It might be worth pointing out
Dear GHC users
If you use GHC 6.0 on Win32, read on. Otherwise, don't bother.
Some of you have already discovered that GHC 6.0 has a nasty bug: if you
go
ghci foo\Baz.hs
and there is any error at all in Baz.hs, then GHC deletes the source
file! This seems like excessive punishment for
oops. Fixed, thank you.
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Kirsten Chevalier
| Sent: 09 July 2003 07:32
| To: [EMAIL PROTECTED]
| Subject: loop reading in external Core
|
| There seems to be a bug in the latest version of GHC
Ah, yes. Fixed.
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Kirsten Chevalier
| Sent: 09 July 2003 00:25
| To: [EMAIL PROTECTED]
| Subject: External Core front end is completely broken
|
| Using the latest version of GHC downloaded from CVS,
]
| Sent: 11 July 2003 08:51
| To: Simon Peyton-Jones; [EMAIL PROTECTED]
| Cc: [EMAIL PROTECTED]
| Subject: Predicativity
|
| Dear Simon, dear Mark,
|
| I had a very cursory look at your Practical type inference for
| arbitrary-rank types paper. One thing that catched my attention
| was the remark
Trouble is, GHC does not distinguish specialisation rules in any way.
-fno-specialisation says not to *generate* any specialisation rules;
-frules-off says not to *apply* any rules.
I suppose you are distinguishing specialisation rules by their name --
whether they start SPEC That'll work,
good point. I've reorganised it a bit now
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
| Behalf Of Wolfgang Jeltsch
| Sent: 28 July 2003 00:27
| To: GHC Bugs
| Subject: documentation headline
|
| Hello,
|
| the headline of section 7.4.5 of the current
Just conservatism. Imagine
newtype T = MkT [T] deriving(Eq)
You'd get
instance Eq [T] = Eq T
which will make the type checker loop for sure. I'm not sure what a
safe approximation might be. But I'll put your example in a comment in
the source code as an example of a safe one
I'm redirecting this to ghc bugs and cvs-ghc.
The conclusion is that 'make install' on Win32 is currently broken.
(Mostly people install from the .msi installer, which is why it's not
much exercised.) I doubt it's really hard, just ticklish.
Does any Win32 expert feel like fixing it? We'd be
.
mail-dub.microsoft.com #5.5.0 smtp;554 [EMAIL PROTECTED]:
Sender address rejected: Access denied
]
Simon
| -Original Message-
| From: Mike Thomas [mailto:[EMAIL PROTECTED]
| Sent: 29 July 2003 11:06
| To: Simon Peyton-Jones; Michael Adams
| Cc: GHC bugs; [EMAIL PROTECTED
| You'd get
|
| instance Eq [T] = Eq T
|
| which will make the type checker loop for sure.
|
| Actually not.
|
| swan(102)% cat Deriving.hs
| newtype N = N [N] deriving Eq
What it's doing is *first* trying the new newtype-deriving stuff,
failing (because recursive) and then trying
801 - 900 of 3117 matches
Mail list logo
