submit a Trac ticket saying how to reproduce? You
might need to bundle up the library too, to make sure we can reproduce it
precisely.
Thanks
Simon
From: Bryan O'Sullivan [mailto:b...@serpentine.com]
Sent: 17 November 2009 07:14
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subject
| 1) Can I profile my program if I don't have all the libraries it depends
| on compiled with profiling?
I'm afraid not. It's one of the shortcomings of GHC's profiler, but it's hard
to overcome.
Simon
___
Glasgow-haskell-users mailing list
Bryan
| I'm working on measuring and improving the performance of the text library at
the
| moment, and the very first test I tried demonstrated a piece of behaviour
| that I'm not completely able to understand. Actually, I'm not able to
| understand what's going on at all, beyond a very
| I think (untested) that in this particular case you can get around the
| problem using scoped type variables:
|
| g :: forall a. Num a = T a - T a
| g x = f x (42 :: a)
|
| In fact, this seems to be the general pattern for fixing problems like
| this with type families: add extra witness
| Is there any difference between -XImpredicativePolymorphism and -
| XImpredicativeTypes?
No there isn't. There's only one flag, -XImpredicativeTypes.
| Hyena uses the latter, and we're using Hyena somewhat in anger.
Interesting. I hope you can get along without it, perhaps with a bit more
| First I thought I would examine the source code of template-haskell
| (more specifically qLocation and qReify) to figure out how to do it
| but got stuck. Obviously I have still much to learn when it comes to
| Haskell.
|
| Could someone explain how Quasi works?
Have you read the paper?
| do { a - getChar
|; rec { b - f c
| ; c - g b }
|; putChar c
|; return b }
| This last point notwithstanding,
| I find the scoping rules very unintuitive!
| (b and c appear to escape their apparently nested scope.)
well you are happy with
do {
:-)
Simon
| -Original Message-
| From: Lennart Augustsson [mailto:lennart.augusts...@gmail.com]
| Sent: 29 October 2009 10:25
| To: Bulat Ziganshin
| Cc: Simon Peyton-Jones; GHC users
| Subject: Re: Update on GHC 6.12.1
|
| Bulat, that would not be in the ghc tradition of breaking existing
| Analogously, is
|
| | do { a - getChar
| |; rec { b - f c
| | ; c - g b }
| |; putChar c
| |; return b }
|
| equivalent to
|
| | do { a - getChar
| |; rec { b - f c
| | ; c - g b } in do
| | { putChar c
| |
Folks
This is an update on the status of GHC 6.12.
FIRST, as you probably know, Hackage and the Haskell Platform is
allowing GHC HQ to get out of the libraries business. So the plan is
- We release GHC 6.12 with very few libraries
- Bill Library Author downloads GHC 6.12 and tests his
| -- If it exports any prelude indentifiers (not only the Prelude itself,
|but also for example Data.List), I have no idea how to get at
|their types --- lookupGlobalName does not find them.
Well, it claims that it should find them. Would you like to make a
reproducible test case and
Question: is the template-hask...@haskell.org mailing list still useful?
* It has 250 subscribers compared to 850 for ghc-users.
* It has low traffic
* template-haskell is the only GHC-specific mailing list associated with a
particular
language feature. Eg type functions, ghci,
[ccing ghc-users]
| I'm trying to extract the names and types of exported functions in a module.
Quite a reasonable request. But it's not conveniently possible at the moment.
Here's what you can do in the Q monad:
class (Monad m, Functor m) = Quasi m where
-- Fresh names
qNewName
Thanks. I've fixed this.
Ian: pls merge if time.
Simon
Fri Oct 2 12:15:49 BST 2009 simo...@microsoft.com
* Fix pretty-printing precedence for equality constraints
M ./compiler/types/TypeRep.lhs -1 +7
From: glasgow-haskell-users-boun...@haskell.org
://research.microsoft.com/~simonpj/papers/hmap
| -Original Message-
| From: Stefan Holdermans [mailto:ste...@cs.uu.nl]
| Sent: 09 September 2009 14:38
| To: Manuel M T Chakravarty; Simon Peyton-Jones
| Cc: glasgow-haskell-users; haskell-cafe; José Pedro Magalhães; Thomas van
Noort;
| Johan Jeuring
: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Evan Laforge
| Sent: 12 August 2009 23:59
| To: Simon Peyton-Jones
| Cc: Augustsson, Lennart; haskell; GHC users
| Subject: Re: [Haskell-cafe] generalize RecordPuns and RecordWildCards to work
with
| qualified
Yes indeed
http://hackage.haskell.org/trac/ghc/wiki/Building/Using#RebuildingtheGHCbinaryaftermakingchanges
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Tim Chevalier
| Sent: 19 August 2009 00:15
Oh, now I get it, thanks. This message concerns design choices for
record-syntax-related GHC extensions. Lennart, pls tune in. You don’t need to
have read the thread to understand this message.
| I think that Even refers to an example like this:
|
| module A where
| data A = A { a :: Int
It should be pretty much linear (modulo a log(n) factor, but then log(n) is
practically constant (=64 or so).).
But people often report that GHC is slow (perhaps non-linearly so) when
compiling vast blobs of literal data. Because there is a reasonable workaround
(just parse the data), which
Gunther
Could you make a Trac bug report for this, and attach your source file?
It'd help if you could first check that things are still bad with GHC 6.10.4.
Another useful thing would be to provide data on whether the behaviour is
non-linear. Eg try with 1k, 2k, 4k, 8k, etc elements in your
Justin
Presumably DeliveryManagementQueries uses TH to generate lots of glop?
*** Desugar:
Result size = 616,969
That's a big program! What kind of glop is it?
Maybe it's the same kind of thing as one of these?
| On Friday 10 July 2009 5:03:00 am Wolfgang Jeltsch wrote:
| Isn’t ExistentialQuantification more powerful than using GADTs for
| emulating existential quantification? To my knowledge, it is possible to
| use lazy patterns with existential types but not with GADTs.
|
| 6.10.4 doesn't allow
I've fixed GHC's pretty-printer to print do-notation using braces and
semi-colons, which is much more robust. I hope that's useful
SImon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Jan
Nice idea, but I'm not yet convinced that it would work well in practice.
First, there's an exponential explosion in the number of constructors required.
Anything with an exponential is worrying.
Second, you presumably do not want massive code duplication. So I assume that
if you start with
Thanks. You've found a bug in 6.10, which is happily fixed in the HEAD and in
the upcoming 6.12. Here's the code for g2:
Test.$s$wg2 =
\ (sc_soL :: GHC.Prim.Int#) (sc1_soM :: GHC.Prim.Int#) -
case GHC.Prim.# sc_soL 10 of _ {
GHC.Bool.False -
case GHC.Prim.=# sc1_soM sc_soL
I believe that you are asking about type functions. Specifically, I think what
you are asking is this:
How can I normalise a type, by rewriting it exhaustively using
the top-level type-function definitions
I think the function TcTyFuns.tcNormaliseFamInst (rather an odd name!) does
I've dumped all this on a release plans wiki page:
http://hackage.haskell.org/trac/ghc/wiki/Status/Releases
Manuel, Duncan: maybe you can modify the wiki directly?
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
|
| That's why one should really be allowed to group constructor's in a
| type's definition:
|
|data Colour :: * where
| Red, Green, Blue :: Colour
Indeed. GHC allows this now. (HEAD only; will be in 6.12.)
Simon
___
Glasgow-haskell-users
| However, one thing will probably not be answered there, since it is more of an
| implementation issue: Is there any function that will guarantee all Uniques in
| a CoreExpr will be completely unique? This is stronger than de-shadowing,
| since I also want Uniques in completely different branches
| I would thus like to propose the following formalisation of the
| ExplicitForall extension:
What you suggest would be fine with me. Presumably ExplicitForall would be
implied by RankNTypes and the other extensions?
There is a danger of having too *many* choices.
I don't mind what keyword (or indeed syntax) we use! Better alternatives
welcome.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Neil Mitchell
| Sent: 21 June 2009 19:15
| To:
Matthis
| Now, from the name Unique, one would assume that each different identifier
| in a compiler run gets a different Unique, even when they are in different
| functions or modules. However, I've found some evidence to suggest otherwise.
Indeed, that's not so.
The thing to read is Section 4
| The reason why ctypedoc and ctype were so different before, is because
| they drifted apart after ctypedoc was added. ctype was changed (I
| think during implementation of the TypeFamilies extension) without any
| changes to ctypedoc. This was fixed in HEAD not so long ago.
|
| Thanks a
John
| When compiled with -fno-pre-inlining, my test program gives a
| different result than compiled without (0.988... :: Double, compared
| to 1.0). It's numerical code, and was originally compiled with
That's entirely unexpected. I am very surprised that turning off pre-inlining
a) affects
Philip
Thanks for your msg (which appears in full below for reference.)
| data RecContTest a where
| C { showable :: Show a = a } :: RecContTest a
This definitely isn't going to work: it declares the 'showable' field to be a
function that *requires* a Show context, not one that *provides* a
Vladimir
[NB: the subject line is wrong: this email is all about impredicativity, and
not at all about higher-rank types.]
| This does not type-check:
| {-# LANGUAGE RankNTypes, ImpredicativeTypes #-}
| f :: [forall a. t a - t a] - t b - t b
...
| But this, very similar, does type-check:
The
Message-
| From: Duncan Coutts [mailto:duncan.cou...@worc.ox.ac.uk]
| Sent: 05 June 2009 01:31
| To: Simon Peyton-Jones
| Cc: Max Bolingbroke; Niklas Broberg; GHC-users; Haskell Libraries
| Subject: RE: Three patches for cabal
|
| On Thu, 2009-06-04 at 08:43 +0100, Simon Peyton-Jones wrote
I'd be quite happy to rename the flag to GeneralisedisedListComp, and clarify
the user manual. Would that suit everyone?
I suppose the alternative is to leave it as TransformListComp, and document
that fact. But I rather agree that GeneralisedListComp fits the literature
better.
Simon
|
It sounds like a bad performance bug to me! Newtypes should not cost
efficiency. Please to submit a Trac bug report.
What would really help is a self-contained program that demonstrates the
problem. Maybe that's what you've supplied. I'm confused though. You say
If I remove any of
Good idea. I've substantially improved this. In HEAD.
Thanks for the suggestion.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Daniel Schüssler
| Sent: 16 May 2009 16:11
| To:
.
Simon
From: Matt Morrow [mailto:moonpa...@gmail.com]
Sent: 28 May 2009 00:08
To: Simon Peyton-Jones
Cc: Ross Mellgren; Haskell Cafe; GHC users
Subject: Re: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types
Spectacular!
How difficult would it be to implement splicing in decls? I'm
That certainly sounds odd to me. As Jules says, try -fno-state-hack (a bit of
a shot in the dark, because we don't have the full context). I hope someone
can help you characterise it a bit more accurately, so you can report it as a
Trac bug.
Simon
| -Original Message-
| From:
Folks
Quite a few people have asked for splices in Template Haskell *types*, and I
have finally gotten around to implementing them. So now you can write things
like
instance Binary $(blah blah) where ...
or f :: $(wubble bubble) - Int
as requested, for example, in the message
| I'd be happy to be proven wrong in this, of course!-) I had the feeling
| that there'd been some recent work on all this and, indeed, reddit has:
|
|
http://www.reddit.com/r/haskell/comments/8mbar/finding_the_needle_stack_traces_for_g
| hc_pdf/
Sorry I've been very buried recently. Some brief
Yes indeed
http://www.haskell.org/ghc/docs/latest/html/users_guide/assertions.html
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Peter Hercek
| Sent: 18 May 2009 10:46
| To:
| GHC's optimizer needs serious work. Personally, I'm rooting for the
| LHC/JHC guys, because I'm increasingly coming to the conclusion that
| you need whole-program compilation with flow analysis and bucketloads
| of specialisation on the back of that to make serious progress at
| optimizing
Aha. Could you find a moment to fix the wiki page? It's a wiki.
thanks
S
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Jason Dusek
| Sent: 20 May 2009 14:44
| To: Simon Peyton-Jones
| Cc
No, the shortcomings are not documented I'm afraid. It's a squishy question
because when you add guards and view patterns it's undecidable whether patterns
overlap or are exhaustive.
Still, GHC's current implementation is poor. It's a well-contained project
that is awaiting a competent
should generate the same code!
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Serge D. Mechveliani
| Sent: 15 May 2009 09:00
| To: glasgow-haskell-users@haskell.org
| Subject: comprehension vs `map'
this helps a bit
Simon
| -Original Message-
| From: Colin Paul Adams [mailto:co...@colina.demon.co.uk]
| Sent: 08 April 2009 11:04
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Functions for builtin operators (?)
|
| Simon == Simon Peyton-Jones simo
Definitely a bug, thank you! I've created a Trac ticket for it.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Jan Jakubuv
| Sent: 05 May 2009 11:06
| To: glasgow-haskell-users@haskell.org
|
Yes, indeed, see http://hackage.haskell.org/trac/ghc/ticket/3012
Incidentally, the main Haskell list isn't the right place for GHC-specific
questions. glasgow-haskell-users@haskell.org is the place
Simon
| -Original Message-
| From: haskell-boun...@haskell.org
Nowhere. It's a name generated by GHC itself during compilation.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Colin Paul Adams
| Sent: 08 April 2009 10:33
| To:
Yes it's documented in the user manual
http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#gadt-style
Since you didn't find it, despite looking, can you suggest how we could improve
the manual so that you would?
Thanks
Simon
From:
The overlap warning checker simply doesn't take account of GADTs. There's a
long-standing project suggestion to fix this:
http://hackage.haskell.org/trac/ghc/wiki/ProjectSuggestions
Perhaps a good GSoc project.
Simon
From: glasgow-haskell-users-boun...@haskell.org
The HEAD and several other packages travel together: if you update one you must
update the others.
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries
In this case you need to update template-haskell.
Simon
| -Original Message-
| From:
| It would be nice if we could first reach a common understanding, so
| that I can actually report the right problem, not just isolated symptoms.
It's quite simple. The Reports specifies the semantics, not the operational
behaviour. Any implementation that behaves as the Report specifies is OK.
| Simon: there aren't really any patterns to combine in the test case,
| so I assume the reordering happens when combining a single
| pattern? Fill the fix you envisioned also cover the IsString variant?
yes it will.
S
___
Glasgow-haskell-users mailing
Indeed GHC does not attempt to retain the order of alternatives, although
a) it might be possible to do so by paying more attention in numerous places
b) GHC may do so already, by accident, in certain cases
Observations:
* The issue at stake is a small one: not the *number of tests* but *which
| You could imagine a pragma to say which branch is likely.
| f p1 = e1
| f p2 = {-# LIKELY #-} e2
| f p3 = e3
|
| Is there some way to propagate pragmas through core transformations?
Not robustly. We do have Notes attached to core, which are more or less
propagated though, but I make not
| This is a real headache. To be frank, controlling lazy evaluation and
| sharing to get the right complexity for your code can be hard enough at
| the best of times, without the compiler sometimes ignoring the sharing
| you try to ask for...
Yes, I agree. The trade off is that without the hack
[Redirecting to GHC users.]
| Tom Schrijvers wrote:
| The cyclic dictionaries approach is a bit fragile. The problem appears to
| be here that GHC alternates exhaustive phases of constraint reduction and
| functional dependency improvement. The problem is that in your example you
| need both
Claus, Max
| My preferred spec would be roughly
|
| {-# NOINLINE f #-}
| as now
|
| {-# INLINE f #-}
| works as now, which is for non-recursive f only (might in future
| be taken as go-ahead for analysis-based recursion unfolding)
|
| {-# INLINE f PEEL n #-}
| inline calls
| What I don't understand yet is the routemap for replacing -fvia-C
Good points, Claus. I think the story is as follows:
* -fvia-C does not produce much better code, except in exceptionally tight
loops, because GHC gives gcc very little scope for optimisation. Simon
mentioned something like
Dan's example fails thus:
| Map.hs:25:19:
| Couldn't match expected type `Nest n1 f b'
|against inferred type `Nest n1 f1 b'
| In the expression: fmap (deepFMap n f)
| In the definition of `deepFMap':
| deepFMap (S n) f = fmap (deepFMap n f)
|
| for reasons I
good idea. done
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Brian Bloniarz
| Sent: 27 February 2009 03:56
| To: glasgow-haskell-users@haskell.org
| Subject: Suggestion for bang patterns
| cite
| The let-binding can be recursive. However, it is much more common for
| the let-binding to be non-recursive, in which case the following law
| holds: (let !p = rhs in body) is equivalent to (case rhs of !p - body)
| /cite
|
| Shouldn't the bang be removed in the final case pattern?
No.
| Until I stumbled over CORE annotations, I found it near impossible even
| to find the pieces of interest for non-trivial programs, things like
| -dsuppress-uniques help a little with diffs, some things look big but
| are noops, etc. - that kind of helpful pragmatic knowledge (why does
| it look
| | A quick grep shows almost no specialization at all for Word, or for
| | IntXX/WordXX (see below). Still, none of that seems to explain the
| | example repeated at the top of this message.
|
| We'd be delighted to apply suitable library patches.
PS: in the case that no one gets around to
| II is where I'd like to be able to distinguish variables, constants,
| and complex expressions in the left-hand sides of RULES, and
| I and III are where I'd like control over the rewrite strategy, as
| in strategy combinators.
I'm deep in icfp submissions, so no time to reply properly.
You
Thank you for a nicely characterised bug report. GHC should never crash! I've
created a trac ticket http://hackage.haskell.org/trac/ghc/ticket/3049
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On
| Ps. It is surprising that performance bugs don't get high
| priority, now that distractions like extralibs are out of the
| ghc picture?
Generally we prioritise bugs that appear to be show-stoppers, and/or are on a
tier-1 platform. Having extralibs out of the way is a help, but as
| Perhaps CPP shouldn't be a pragma, just a command-line flag? It seems
| to be the only one that affects/involves preprocessor(s). AFAICT, the
| others all affect the haskell compiler stage.
Yes, it does seem anomalous. I suppose the motivation is that some modules
might need CPP and some not,
That should not happen. Can you boil out a test case and make a Trac ticket?
When I try the same thing it works:
Spec.hs: f :: Num a = a - a
{-# SPECIALISE f :: Int - Int #-}
f x = x+2
ghc -c -ddump-rules -O Spec.hs
Top-level
I'm guessing a bit here, but it looks as if you intend this:
* GHC should read Foo.hs, and see {-# LANGUAGE CPP #-}
* Then it should run cpp
* Then it should look *again* in the result of running cpp,
to see the now-revealed {-# LANGUAGE DeriveDataTypeable #-}
I'm pretty sure we don't do that;
Friends
| While it is possible that we will fix some others, for the 6.10.2
| release we mainly intend to look at the high-priority bugs in the 6.10.2
| milestone. They are listed here:
|
|
http://hackage.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopened
|
| Hello Peter,
|
| Your efforts are simply outstanding. Thanks a lot for sharing your
| experiences.
Seconded! Very useful stuff.
That said, Simon M and I are not really focused on the debugger right now, so
I'm hoping that someone (Pepe or others helping him) can follow up your
suggestions.
Douglas.
Good suggestion. I believe it's already been proposed that typese are
normalised (wrt type functions) before being displayed, but I can't find the
ticket. Do create a feature request on Trac, with your example. Thanks!
Simon
From: glasgow-haskell-users-boun...@haskell.org
Matthijs
| However, there are two issues bothering me still. The first is that the
| Core types (in particular CoreExpr) are not instances of Show. They are
| instances of Outputable, which allows them to be pretty printed.
| However, this pretty printing is good to view the structure of the
|
Thanks Tyson. Not only for finding the problem, but for fixing it too! We
love that.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Tyson Whitehead
| Sent: Friday, January 30, 2009 5:44 AM
[Redirecting to GHC users]
The loop is a bug. Thank you! I'll Trac it.
Simon
| -Original Message-
| From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org]
| On Behalf Of Sittampalam, Ganesh
| Sent: Monday, January 19, 2009 2:05 PM
| To: hask...@haskell.org
| Subject: RE:
Yes we are. If you aren't using the FFI or unsafe things, you should not get a
seg fault. Do help us to reproduce it -- thanks.
Simon
| -Original Message-
| From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-
| boun...@haskell.org] On Behalf Of Serge D.
| I hardly use any let expressions (shame on me??) and I am not very familiar
| with them. But I figured out you might have mistaken, so I changed the bit
| to:
|antecedent :: Rule - Expression
|antecedent r = case r of
|Ru{} - if (rrsrt r == AlwaysExpr) then error
OK once I bit the bullet and looked at the code the bug was obvious.
When you pattern match
Ru{rrsrt = AlwaysExpr} - error blah
GHC uses, well, pattern-matching to see if rrsrt is AlwaysExpr.
But when you say
Ru{} - if (rrsrt r == AlwaysExpr) then error blah else ...
then GHC
from it.
| I will upload my modules as a zip file, so you can reproduce the error. It
| also contains a README.txt file that explains how to reproduce it.
| Hope that helps.
| http://www.nabble.com/file/p21439653/src.zip src.zip
|
|
| Simon Peyton-Jones wrote:
|
| I agree that's odd. Are you using
I agree that's odd. Are you using -O? Can you give us a reproducible test
case?
(The only think I can think is that the line
|Gc{} - Tm (grspe r)
will build a thunk for (grspe r), and depending on the context I suppose you
might get a lot of those.)
Thanks
Simon
|
[Redirecting to GHC users]
Andres,
Nice example. It's another instance of a problem that keeps coming up with
type families. Details here:
http://hackage.haskell.org/trac/ghc/ticket/1897#comment:10
The rest of the ticket gives other examples. It's not clear what the Right
Thing to do is.
| Thanks very much for this. I would never have guessed to use
| -XRelaxedPolyRec given the error message.
|
| Is it worth noting it here
| http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_GADT_matching
| or is it something that has always existed with GADTs and I just didn't
| trip
| Subject: Re: length of module name affecting performance??
|
| That's a truly awesome feature! I'll shorten all my module names to
| single letters tomorrow.
Awesome indeed :-). Try shortening all your variable names to single letters
to, to see if that helps. Oh, and delete all comments.
I have not followed the details of this thread, but Simon Marlow will be back
in action on 5 Jan and he should know.
What I do know is that this is supposed to happen:
* If a *synchronous* exception S is raised when evaluating a thunk, the
thunk is permanently updated to throw S.
*
| I have a good theory on the latter symptom (the thread killed
| message). Sticking in some traces, as in my appended code, helped me
| to see what's going on. It seems to be exactly what you describe --
| the variable v is permanently bound to the exception it evaluates
| to. Since the right
Which version of GHC are you using? GHC 6.10 implements automatically
precisely the transformation you give below.
If the difference shows up in GHC 6.10, could you spare a moment to produce a
reproducible test case, and record it in GHC's bug tracker?
Thanks
Simon
| -Original
| If I remove -XScopedTypeVariables from this http://hpaste.org/13230 then
| I get the following error message:
|
| Asn1cTestNew.hs:55:27:
| GADT pattern match in non-rigid context for `INTEGER'
|Solution: add a type signature
| In the pattern: INTEGER
| In the definition
Friends
Lots of the bug reports on the GHC bug tracker are platform-specific. We
thought it'd help for us to articulate more clearly what platforms GHC
supports, and what we'd like it to support. Look here:
http://hackage.haskell.org/trac/ghc/wiki/Platforms
What you'll notice is
| I also feel that the type errors given when working with existential
| types, especially GADTs with existentials, are confusing. I think
|
| I am using existential types to test GADT code. See
| http://www.haskell.org/haskellwiki/QuickCheck_/_GADT which no longer
| works with 6.10.1.
Really?
| arbitrarySeq :: Sequence a - Gen RepSeqVal
| arbitrarySeq Nil =
| return (RepSeqVal Nil Empty)
| arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) =
| do u - arbitraryType t
|us - arbitrarySeq ts
|case u of
| RepTypeVal a v -
| case us of
|
| To: Simon Peyton-Jones
| Cc: Neil Mitchell; glasgow-haskell-users@haskell.org; Don Stewart
| Subject: Re: cross module optimization issues
|
| Neil, thank you very much for taking the time to look at this; I
| greatly appreciate it.
|
| One thing I don't understand is why the specializations
Friends
GHC has embodied data type families since 6.8, and now type synonym families
(aka type functions) in 6.10. However, apart from our initial papers there
isn't much published material about how to *use* type families. But that
hasn't stopped you: quite a few people are using them
In my case, we had rigid type signatures all over the place. The wiki document
says that the type must be rigid at the point of the match. I guess that's
what we were violating. If the code I posted isn't supposed to type check then
I would like to report, as user feedback, that GADTs have
It looks as if you are somehow failing to link your binary with package 'base'.
(Are you using 'ghc' as your linker; you should be.) But others are better
than I at this kind of stuff.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL
501 - 600 of 1383 matches
Mail list logo
