I too wish there was a good solution here. I've taken to making dated repos,
thus
http://darcs.haskell.org/ghc-new-co-17Nov10
When it becomes unusable, I make a brand new repo, with a new date starting
from HEAD, pull all the old patches, unrecord them all, rerecord a mega-patch,
and
I think it would help to separate issues.
If it were not for rebindable syntax, there would be no need for these op
fields in (say) BindStmt etc. Instead, we'd have a fixed typing rule for
BindStmt, and the desugarer would use the fixed Control.Monad.(=). The
rebindable syntax thing just
Yes, impredicative types are still in, but in a simpler form than before, along
the lines of QML
http://research.microsoft.com/en-us/um/people/crusso/qml/
I have been too busy with getting the new type checker working to describe or
document it. Notably, I have not yet added syntax for QML's
read the QML paper! that's the trick. simpler, but with a heavier annotation
burden than the more sophisticated approaches
| -Original Message-
| From: Gregory Crosswhite [mailto:gcr...@phys.washington.edu]
| Sent: 19 November 2010 19:59
| To: Simon Peyton-Jones
| Cc: Haskell Cafe
I'm trying to give the user the possibility to jump to the definition of a
symbol in the source file. You click on the name of a function and you're send
to the module where it's defined. So I have an AST, and somewhere down the line
I have an Id object representing that function call. Then I
| Well, I'm aware that it's a compromise. I don't know how to do a bang-up
principled
| job of typechecking local polymorphism, so GHC does a best-effort job. In
fact best
| effort is pretty good, and it's not hard to implement, so
| a) I don't expect to remove NoLocalMonoBinds
|
Interesting. What would it look like in Core? Anyone care to make a ticket?
S
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Roman Leshchinskiy
| Sent: 03 November 2010 10:55
| To:
| Make sure you are using RC2 of the compiler, from what I remember RC1
| required signatures it shouldn't have, or enabled MonoLocalBinds more
| than it should - RC2 required less signatures. However, your code
| could well just be heavily using the relevant features.
|
| I was using
.
Simon
| -Original Message-
| From: Bas van Dijk [mailto:v.dijk@gmail.com]
| Sent: 30 October 2010 21:14
| To: glasgow-haskell-users@haskell.org
| Cc: Simon Peyton-Jones
| Subject: Re: Type error in GHC-7 but not in GHC-6.12.3
|
| On Sat, Oct 30, 2010 at 1:57 AM, Bas van Dijk v.dijk
| To: glasgow-haskell-users@haskell.org
| Cc: Simon Peyton-Jones
| Subject: Re: Type error in GHC-7 but not in GHC-6.12.3
|
| On Fri, Oct 29, 2010 at 5:42 PM, Simon Peyton-Jones
| simo...@microsoft.com wrote:
| That looks odd.
|
| Can you isolate it for us? The easiest thing is usually to start
| On a related note, these are also apparently allowed (in 6.10.4):
| f :: forall a. (Eq a = a - a) - a - a
|-- the Eq context prevents the function from ever being called.
That's not true. E.g.
f ((==) True) True
works fine.
|g :: forall a. Ord a = (Eq a = a - a) - a - a
|
: 22 October 2010 19:50
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subject: Re: context-stack GHC 7.0.1 Release Candidate 1
I was running into a similar issue and haven't noticed a dramatic improvement
with the latest changes. The number of ticks taken to compile are approximately
| | On a related note, these are also apparently allowed (in 6.10.4):
| | f :: forall a. (Eq a = a - a) - a - a
| | -- the Eq context prevents the function from ever being called.
|
| That's not true. E.g.
| f ((==) True) True
| works fine.
|
| What I meant is that f cannot
| An implicit quantification point is
| a) the type in a type signature f :: type or
| b) a type of the form (context = type)
| if it does not start with an explicit 'forall'
|
...
| How inconvenient would it be to make the above description simpler by
| dropping b) and thus
| In a data type decl
| data Foo = Foo (Eq a = a)
| the top of the type is done separately for each argument. After
| all, Foo (Eq a = a) isn't a type. So you get
| data Foo = Foo (forall a. Eq a = a)
|
| This was a surprise as
|
| data Bar = Bar (a - a)
|
| is illegal and
The current story is this:
GHC adds an implicit forall at the top of every type
that foralls all the type variables mentioned in the type
that are not already in scope (if lexically scoped tyvars is on)
This is stated pretty clearly here
| Sent: 12 October 2010 12:47
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: context-stack GHC 7.0.1 Release Candidate 1
|
| Am 08.10.2010 18:52, schrieb Simon Peyton-Jones:
| Christian
|
| We've committed a wave of patches that should substantially improve
| Now that the Glorious New type checker can handle local evidence
| seamlessly, is it a big implementation burden to extend it to deal
| with local *type class instances* in addition to local *equality
| constraints*?
...
| Are there big theoretical problems with this extension, or is it just
| a
Thanks. We knew about this -- in flight changes happening now -- but I've
added it as a new regression test even so.
Simon
| -Original Message-
| From: Christian Maeder [mailto:christian.mae...@dfki.de]
| Sent: 15 October 2010 17:53
| To: GHC Users Mailing List
| Cc: Simon Peyton-Jones
Folks
Following lots of feedback from users, especially at ICFP, I've evolved some
proposals for Template Haskell, that should make it both more expressive, and
more secure.
http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal
Do let me know what you think. Discussion by
Which version of GHC are you using? GHC 6.12 does not complain about unused
variables bound by ... Try this, which complains about y, but not g.
Simon
{-# LANGUAGE RecordWildCards #-}
module Test where
data T = MkT { f,g :: Int }
p (MkT { .. }) y = f
| -Original Message-
| From:
Christian
We've committed a wave of patches that should substantially improve the
typechecker. Could you try with the current HEAD?
(Or you can wait for the next release candidate, end next week; but sooner is
better.)
Simon
| -Original Message-
| From:
Good idea. I've made a new Trac ticket and responded there. I suggest that
others do the same, so the conversation is captured in the ticket.
http://hackage.haskell.org/trac/ghc/ticket/4370
You can add yourself to the cc list of the ticket to stay in the loop.
Of course, do use the mailing
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: GHC 7.0.1 rc1: Could not deduce (Typeable a) from the context
(Typeable
| a, …)
|
| Simon Peyton-Jones wrote:
| Oh dear, that really is quite a strange error message. Something is
| definitely wrong. Can you please
I've been meaning to write a blog post about this, because it's a significant
change. I'll do this when I get home after ICFP. Briefly though:
* If you use -XGADTs or -XTypeFamilies (or -fglasgow-exts, which is deprecated)
you get -XMonoLocalBinds, which says that local let/where bindings
-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Don Stewart
| Sent: 29 September 2010 14:53
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1
|
| I've created a wiki page to track
| Here's a boiled-down equivalent to what the issue is in uvector:
|
| http://hpaste.org/40213/doesnt_work_in_ghc_7
|
| In GHC 6.12, this would have type-checked. In GHC 7, I need to add a
| type-signature to the 'helper' function, except I 'm not sure how to
| do it.
|
| So the
Oh dear, that really is quite a strange error message. Something is definitely
wrong. Can you please make a ticket for it, and include instructions on how to
reproduce it?I gather that it depends on other packages that themselves
needed changes, so reproduction might not be entirely easy?
| (2) ghc-6.12.2 compiles docon-2.11
| (download it via http://haskell.org/ghc/docon/
| and follow install.txt
| )
I get Not found when following http://haskell.org/ghc/docon
Simon
___
Glasgow-haskell-users mailing list
| Except I don't know how to write a type signature for this.
|
| The value 's' passed in is bound by pattern matching on this guy's
constructor:
|
| data Stream a = forall s. Stream (s - Step s a) !s Int
|
| in the top-level function, so I don't even know if it has a type I can name.
We found another occurrence of very poor performance in a smaller program. We
have a nice fix; but won't be able to commit for a few days
Let's hope it fixes your problem too!
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
| For patterns in left hand sides (lhs) of let or where also no warnings
| are issued.
|
| data Foo = Bar Int | Baz
|
| test3 :: Foo - Int
| test3 x = let Bar i = x in i
|
| Will or should these cases be covered, too?
No, I don't plan to warn about these, which is the case at present. It's
Good point. Simon and I have decided we agree. I'll push a patch shortly.
S
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Mitar
| Sent: 21 September 2010 07:44
| To: glasgow-haskell-users
|
I found the spot where the collected RdrNames are used to generate the unused
import warnings, but I don't quite understand where they are gathered. Is there
an AST traversal function somewhere that gathers these RdrNames? If so, I could
use it as a blue print to write my own traversal.
No, it
It probably is linked if you use --make, but should not be if you use an
explicit link command
ghc -o run-me A.o B.o C.o
Just omit LargeThModule.o
Hmm. Maybe this won't work, because there is a module initialisation tree, in
which each module calls the initialisation function of the
Don't I need to work on LHsExpr rather than HsExpr? How would I otherwise get
the location?
Yes, indeed, LHsExpr.
*Binding getExpr (Lam v e) = g_del v (getExpr g e)
I still don't quite the purpose of this
Well if you have (\x - y + x) there is a free occurrence of 'y' but
Johan
GHC already collects all RdrNames for imported things, for use when reporting
unused imports. But it doesn't collect the SrcSpan of the occurrences, nor
does it collect occurrences of locally-bound things.
I suggest you write a general traversal looking like
data Gather var res
=
| I'm afraid I didn't understand your questions well enough to answer them.
|
| My question is, why does this type check:
It's hard for me to answer a question like that! To explain why something type
checks I'd have to show every constraint and how it is solved.
I think you have something
Mitar
I'm afraid I didn't understand your questions well enough to answer them. But
it'd be worth reading
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/other-type-extensions.html#scoped-type-variables
| It's not trivial to add, but not really hard either. Has anyone else been
|
| ghc-6.12.3:
| 89,330,672 bytes allocated in the heap
| 15,092 bytes copied during GC
| 35,980 bytes maximum residency (1 sample(s))
| 29,556 bytes maximum slop
| 2 MB total memory in use (0 MB lost due to fragmentation)
|
|
Mitar, and others
Yes, I've spent most of the last month working on the new type checker, and
unless there's a major hiccup it'll be in GHC 7.0. We'll produce a release
candidate just before ICFP.
However, as it happens both your tests compile with GHC 6.12, if you add
ScopedTypeVariables.
Doesn't look right. I've made a ticket
http://hackage.haskell.org/trac/ghc/ticket/4283
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Mitar
| Sent: 02 September 2010 01:27
| To:
It's a bit of a moveable feast. With -fno-spec-constr-count you allow GHC to
specialise as much as it pleases, which is good for perf (maybe) but can lead
to major code size expansion.
S
From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 31 August 2010 10:16
To: Simon Peyton-Jones
Cc
Kathleen
I talked to Simon. We are puzzled. Maybe a file has moved, so that make
maintainer-clean isn't cleaning it. (That's something the build system is bad
about.)
Can you try in a completely fresh tree? And, if that fails, send (a url to)
the entire build log?
Incidentally
I can’t reproduce this. With the enclosed module and HEAD, I get the warning;
but when I add –fspec-constr-count=5, the warning goes away and I get the
specialised rules.
Could Cabal not be passing on the flag or something?
Simon
module Foo where
data T = A | B | C | D | E
f :: T - [Bool]
It's hard to read your code because the line breaks have been removed.
Moreover I think your code depends on some unspecified Hackage package. And I
couldn't find the enclosed Core dumps. Nor do you specify which version of GHC
you are using.
Still I believe that the nub is this. You have
Sorry, my fault. Simon M is fixing
S
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Johan Tibell
Sent: 26 August 2010 09:08
To: glasgow-haskell-users
Subject: HEAD unbuildable
I'm having trouble building HEAD, to the point where
Data constructor workers don't have bindings: they just stand for themselves.
Wrappers do have bindings, but the easiest way to get them is to get them and
ask for their unfolding (via unfoldingTemplate . idUnfolding).
So you just need to get the Ids. You can get them from the global type
| {-# LANGUAGE GADTs #-}
| module Foo where
|
| data TemplateValue t where
| TemplateList :: [x] - TemplateValue [x]
|
| instance (Eq b) = Eq (TemplateValue b) where
| (==) (TemplateList p) (TemplateList q) = (==) p q
A good example. Yes, GHC 6.12 fails on this and will always fail
Dear TH users
In Template Haskell, it's not currently possible to say give me all the
instances of this class; it's a long-standing feature request.
Sam Anklesaria has come up with a design and implemented it. Before committing
to it, I want to check that other Template Haskell users are happy
You don't want to go overboard here.
1. You *want* a distinct blob of lookup code for each different key type,
because you really do want a different lookup structure for each
2. For the most part you *dont want* a different blob of lookup code for
each value type, because almost
| SPECIALISE pragmas are not supported in any but the defining module
| because the Core for a function to specialise is not guaranteed to be
| available in any other module. I don't think there is any other
| barrier.
Yes, exactly.
| It is possible to imagine implementing a remedy for this by
| Knowing that, I'd like to be able to resolve (Show a, Monad m) as
| (Show [Char], Monad IO). Put more simply, I'd like the applyInst
| expression to typecheck as the apply expression does. Reading through
| the OutsideIn paper over the weekend, I began to understand why it
| isn't so simple.
Matt
I afraid I didn't understand your email well enough to offer a coherent
response. For example I have no clue what instance unifs might mean. Nor do
I understand what your program seeks to achieve.
Thomas is right to say that the type checker is in upheaval at the moment. I'm
actively
:46
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subject: Re: Casting + eta reduction
Or a different way:
I want -fdo-lambda-eta-expansion (which, if I understand correctly, actually
triggers eta *reduction*) to eliminate argument casts, as well.
My motivation: I'm working
| The head has -dsuppress-coercions which omits coercion terms when pretty
| printing Core. It would be easy to backport that to 6.12.
The HEAD also has a coercion optimiser that dramatically shrinks some large
coercion terms.
| I might revert both mwc-random and statistics back to using plain
It compiles to
lift f d = f (d `cast` blah)
which seems fine to me. Are you unhappy with that?
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Louis Wasserman
Sent: 09 July 2010 03:30
To: glasgow-haskell-users@haskell.org
]
| Sent: 12 July 2010 01:56
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Massive slowdown in mwc-random after switching to use of
| primitive package
|
| On Sunday 11 July 2010 1:31:23 pm Simon Peyton-Jones wrote:
| This is the first I've heard of this. Do you have
Thank you! I am utterly buried just now (POPL) but will get to this.
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Bryan O'Sullivan
Sent: 12 July 2010 13:58
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
| caused a huge performance regression.
|
| You're using GHC 6.12.x presumably? There are known performance problems with
| using abstract PrimMonads in that version (and, actually, just using IO as
| well).
...
| The good news is that, last I checked, this isn't a problem in HEAD. The
|
| Here's a concrete case I recently ran into:
|
| type family SomeOtherTypeFamily a
| class SomeClass a where type SomeType a
| instance a ~ SomeOtherTypeFamily b = SomeClass a where
|type SomeType a = (b,Int)
|-- (error) Not in scope: type variable `b'
|
| The same thing
There have been a couple of emails about Template Haskell support for
· GADTs
· View patterns
· Reifying instances
There’s a ticket for this already
http://hackage.haskell.org/trac/ghc/ticket/3497
It’s mainly a library design question, in this case the design of the
Robert
Great example! Your test case makes the type checker work hard to produce
solve the type-equality constraints (and you have a lot of them); when
pretty-printed it comes to 7000 lines! But these large proofs are readily
simplified to something tiny, just a few lines.
As luck would
See my comment http://hackage.haskell.org/trac/ghc/ticket/4028#comment:4
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Seyed Hosein Attarzadeh Niaki
| Sent: 27 April 2010 20:41
| To:
It's a bug, but it's been fixed
http://hackage.haskell.org/trac/ghc/ticket/3833
Thakns
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Ben
| Sent: 04 May 2010 06:55
| To:
| Does this mean DPH is ready for abuse?
|
| The wiki page sounds pretty tentative, but it looks like it's been awhile
| since it's been updated.
|
| http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell
In truth, nested data parallelism has taken longer than we'd hoped to be ready
for
| Again, my question is: suppose the following code is given:
|
| module Test (R(..)) where
| data R = R { x :: Char, y :: Int, z :: Float }
|
| and :browse of GHC 6.12 displays:
|
| data R = R {x :: Char, y :: Int, z :: Float}
| data R = R {x :: Char, ...}
| data R = R {..., y :: Int, ...}
|
| I compiled my code with -fdicts-strict.
|
| What is this actually supposed to do? It seems the documentation is
| missing:
| http://www.haskell.org/ghc/docs/latest/html/users_guide/options-
| optimise.html#options-f
|
| From reading the source code, it appears to make any dictionary fields
| This is not strictly a GHC question. I observed that ld when linking
| GHC-compiled programs eats 0.5 GB of resident memory. ~3 times more than
| GHC or Haddock. So if there is not enough free memory ld uses virtual
| memory and works very slowly (practically does not use CPU). I'd like to
|
John
| I'm not the original reporter, but I can confirm that I am able to
| install Criterion-0.5.0 with ghc-6.12.1 on OSX 10.6. One datum,
| anyway.
|
| The problem isn't with criterion itself, but with vector-algorithms.
| The vector library relies heavily on type families, which have dodgy
|
| My intention was to use a GADT as data family instance (hence, I
| wrote it in GADT style and it was accepted as such). Can't GADTs be
| used as data family instances?
|
| I'm not aware of any restriction there, but that's not the issue here.
|
| You were trying to choose between different
Can you check? If it still happens with 6.12, please submit a bug report.
If 6.10 can't compile criterion, you might want to add a constraint to the
Cabal meta-data.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
|
It's really a bug. I've fixed it in my tree, but I'm at 2.8 and don't have time
to validate etc. So I'm doubtful that I'll be in time to get a fix into
6.12.1, alas.
Well, maybe I can build a patch and send it to Simon/Ian for testing. I'll try
to do that if it's important to you.
it's bit
The standalone deriving decl you need is the one for (Data (a :+: b)), not for
Expr
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Ron Alford
| Sent: 12 April 2010 11:09
| To: Simon Peyton
| type family T a :: *
| my_id :: f a - f a; my_id = id
| x :: T a - T a; x = my_id
|
|
| IMHO, this was not clear from the documentation or from the error
| message (It certainly _looks_ like T a should match f a...).
| Thanks for the explanation.
Did you read this?
Friends
Can anyone help Kathleen out? She has a cabal-install issue. I think she's on
a Mac.
Many thanks
Simon
From: Kathleen Fisher [mailto:kathleen.fis...@gmail.com]
Sent: 16 February 2010 22:54
To: Simon Peyton-Jones
Subject: Fwd: Installing syb(-0.1.03) package in head version
, Alistair
Cc: Simon Peyton-Jones; GHC users; cvs-...@haskell.org
Subject: Re: Installing syb(-0.1.03) package in head version of Haskell
I'm guessing that is indeed the problem, though I cannot reproduce the error
(but I'm using Cabal-1.8.0.2).
Assuming this is the cause of the problem, what is the best
Tyson and others
Would you like to gather some of what you have learned into a user-oriented
Wiki page about how to use shared libraries in GHC? The right place for this is
http://haskell.org/haskellwiki/GHC
under Contributed documentation.
You probably have all the material in the
This is a tricky one. The motivating example is this:
-- Overlapping instances
instance Show a = Show [a] where ...
instance Show Char where ...
data T where
MkT :: Show a = [a] - T
f :: T - String
f (MkT xs) = show xs ++ \n
Here it's clear that the only way to discharge the
| Hello Simon and others,
|
| unfortunately, I missed this e-mail.
|
| Yes, removal of impredicative polymorphism hurts me, since impredicativity
| plays a crucial role in the Grapefruit FRP library at the moment. This is
| described in section 5 of my paper “Signals, Not Generators!” [5]. It’s
Robert
Interesting example. Here's your code:
createInstance' :: Q Type - Q Dec
createInstance' t = liftM head [d|
instance Foo $t where
type FooType $t = String
|]
When TH sees a quotation, it *typechecks* it. So it tries to typecheck
. The current setup seems
quite good.
Simon
| -Original Message-
| From: omega.th...@gmail.com [mailto:omega.th...@gmail.com] On Behalf Of Max
| Bolingbroke
| Sent: 01 February 2010 14:25
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org; Kathleen Fisher;
| mainl...@eecs.harvard.edu
-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Sebastian Fischer
| Sent: 02 February 2010 11:04
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org; Kathleen Fisher;
| mainl...@eecs.harvard.edu
| Subject: Re: Quasi quoting
|
| Dear
| If I understand Brad correctly, then what he needs is what he called
| pattern quotation rather than splicing.
...
|
| Is there a problem with adding support for pattern brackets on the
| right-hand side of function definitions in order to simplify the
| definition of quasi quoters?
Oh, thank
| Or we could switch to different quotation brackets altogether for
| quasiquotation, the obvious possibility being |...blah...|, and
| pads|...blah...|. That would not be hard, and would only affect the
| handful of current quasiquote users. But it'd remove | and | as a
| valid
| My question: Are Template Haskell pattern quotations (i.e., [p| ...
| |]) not implemented in GHC because they are rather tricky to
| implement, or because there has not been demand for them?
They are tricky! The trouble is that patterns *bind variables*. I don't know
how to deal cleanly
| quotations of the form [| |] (i.e. no 'language' specified) will
| use an implicit parameter* ('quasi', say) of type QuasiQuoter, if in
| scope. Otherwise, they will behave as they currently do (TH
| expression quotation?). Now to awaken the 'pads' magic (or some other
| magic), you'd do
Dear GHC users
This email is to announce two proposed changes to GHC's quasi-quotation
mechanism. For all I know, no one is using quasi-quotation (although it's a
very cool feature, thanks to Geoff Mainland), but I didn't think I should take
it for granted!
The current spec is here:
| Also, is Hoopl expected to be used on core - core plugins, and, if so, is
| the
| infrastructure in place for this?
no, Hoopl works on imperative control flow graphs, the C-- part of the back
end, not on Core.
Simon
___
Glasgow-haskell-users mailing
-Original Message-
From: Simon Peyton-Jones
Sent: 28 January 2010 07:50
To: 'austin s'
Subject: RE: GHC core plugins
compiler/cmm/ZipDataFlow.hs
But we have great ideas for making it much simpler and more modular. In
progress..
S
| -Original Message-
| From: mad
Yes, I apologise for being slow about this. A good idea would be to create a
Trac ticket, so that people can register interest in having the patch by adding
themselves to the cc list. The more people that want it, the higher up my
priority list...
Better still if everyone adds a comment to
GHC doesn't have any way to let you plug in new error messages. I imagine
you mean in the type inference engine?
Can you characterise more precisely what you want, perhaps by example.
I do urge you to read the Utrecht work; they have done tremendous stuff on
user-defined type rules and
Looks like a bug to me! I am currently elbows-deep in re-engineering GHC's
entire constraint generation and solving mechanism, which will, I hope, simply
solve your problem.
But meanwhile can I ask a favour: submit a Trac report with the offending code
in reproducible form? Then I'll be
All: as Robert says, I keep meaning to close the template-haskell list
altogether; but I am not sure how to do so.
Jonathan: where did you find a pointer to the mailing list? I should remove
those too.
Returning to the question, sadly there's no way to do what you want right now.
There's an
Yes indeed; see
http://hackage.haskell.org/trac/ghc/ticket/3202
http://hackage.haskell.org/trac/ghc/ticket/3217
One-line summary: we have a spec, but no volunteer.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
|
Yes I did. That too was an oversight. Thanks for pointing both out.
S
| -Original Message-
| From: Bas van Dijk [mailto:v.dijk@gmail.com]
| Sent: 07 January 2010 08:44
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Associativity of ViewPatterns
Good point. I'll fix that, in HEAD at least.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Bas van Dijk
| Sent: 06 January 2010 12:44
| To: glasgow-haskell-users@haskell.org
| Subject:
The paper on System FC [1] has an operational semantics. Would that do?
Simon
[1] http://research.microsoft.com/~simonpj/papers/ext-f
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Matthijs
Should this go in a FAQ? For GHC? Or for a particular architecture?
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Antoine Latter
| Sent: 28 November 2009 23:01
| To: Yusaku Hashimoto
| Cc:
| For ghc-6.12, we should just fix ticket #3681.
OK, good. But who is we?
Simon
| -Original Message-
| From: libraries-boun...@haskell.org [mailto:libraries-boun...@haskell.org] On
Behalf
| Of Duncan Coutts
| Sent: 30 November 2009 10:41
| To: Simon Peyton-Jones
| Cc: glasgow
401 - 500 of 1383 matches
Mail list logo
