| 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 prom
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 te
| 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 a
[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 bo
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 #-}
| >inl
| 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 1
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 don'
| | 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 creati
| 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
|
| 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)
|
|
| Shouldn't the bang be removed in the final case pattern?
No. If p was
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 documentat
| 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 can
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 Behal
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 speci
| 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,
| 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 you'
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=new&status=assigned&status=reopened
| &priority=high&prior
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;
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
[mailto:
| 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.
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
| exp
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 <> 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: [H
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. Mechvel
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 ...
the
| 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 ("
p and I use the
| defaults 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:
| >
| &
[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.
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
| -
Reid,
Ah yes. The interaction of functional dependencies and GADTs is flaky and
unpredictable in both 6.8 and 6.10. It's actually rather tricky to get right
-- see our ICFP'08 paper.
You may have better luck using type families instead of functional
dependencies, but even then 6.10 isn't rea
| 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 ove
| 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 definiti
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 Message---
| 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
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".
*
| 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
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 that
:07
| 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 specializat
u can get
specialised versions by a SPECIALISE pragma, or SPECIALISE INSTANCE
Does that make sense?
Simon
| -Original Message-
| From: Neil Mitchell [mailto:[EMAIL PROTECTED]
| Sent: 28 November 2008 09:48
| To: Simon Peyton-Jones
| Cc: John Lato; glasgow-haskell-users@haskell.org; Don St
| > 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 ->
| > c
| > 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
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 alread
Did you try giving a type signature to the (entire) case expression, as I
suggested? That should do it.
Perhaps I don't understand the suggestion, but for me the only way I could fix
it was to put all the pattern matches into local functions with type
signatures. I can show you the diffs if yo
Ah hum. We probably have not compiled GHC 6.8 with 6.2 for some time. Worse,
we don't even clearly document what the oldest version is that should bootstrap
any given version.
Ian: could you extend the building guide
http://hackage.haskell.org/trac/ghc/wiki/Building (perhaps the "what tools y
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 PROTECTE
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 be
You need a type signature for the case expression. As Daniel says, this is
worth a read
http://haskell.org/haskellwiki/Upgrading_packages%23Changes_to_GADT_matching#Changes_to_GADT_matching
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL PRO
| > I've actually been experimenting with something similar:
| >
| > darcs get http://code.haskell.org/~judah/ghci-haskeline/
| >
| > Current benefits over the readline/editline versions:
| > - Works on Windows
|
| I can attest to that. Nice going Judah!
|
| $ cabal update
| $ darcs get http:
| This project is based on Oleg's Iteratee code; I started using his
| IterateeM.hs and Enumerator.hs files and added my own stuff to
| Enumerator.hs (thanks Oleg, great work as always). When I started
| cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my
| minimal test case inc
Would it be worth adding this hard-won lore somewhere on a Wiki where it can be
found later?
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Duncan Coutts
| Sent: 07 November 2008 18:09
| To: GHC-users list
| Cc: Philip
| I'm compiling with -O2 -Wall. After looking at the Core output, I
| think I've found the key difference. A function that is bound in a
| "where" statement is different between the monolithic and split
| sources. I have no idea why, though. I'll experiment with a few
| different things to see
| > In your case the error message was:
| >
| > GADT.hs:26:56:
| >GADT pattern match with non-rigid result type `Maybe a'
| > Solution: add a type signature
| >In a case alternative: I1 m' -> m'
| >In the expression: case w' S of { I1 m' -> m' }
| >In a case alternative: Wrap w
| > BUT people who care probably UNPACK their strict fields too, which
| > is even better. The time you can't do that is for sum types
| >data T = MkT ![Int]
|
| You also can't do it for polymorphic components. I've used code like:
|
|data T a = MkT !a
|
|foo :: T (a,b) -> a
|f
| I totally agree. Getting the value of the field should just evaluate
| x and then use a pointer indirection; there should be no conditional
| jumps involved in getting the value.
| GHC is just doing the wrong thing.
You're right. As Simon says, GHC's Core language has no type distinction
betw
| After installing ghc 6.10-rc, I have a program that
| no longer compiles. I get the dreaded "GADT pattern match"
| error, instead :)
I'm sorry it's dreaded! Jason is right that the key point is this:
GHC now enforces the rule that in a GADT pattern match
- the type of the scrutinee
| http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_
| 6.10
| >
| > It collects the 7 or so known issues that break code with GHC 6.10.
| > Please feel free to clean up, and especially *add techniques for
| > handling each change*.
| >
| > If we do this right, with cabal-
| while both GHC and Hugs accept this variation:
|
| class FD a b | a -> b
| f :: (FD t1 t2, FD t1 t3) => t1 -> t2 -> t3
| f x y = undefined
|
| and infer the type of 'f' to be 'f :: (FD t1 t3) => t1 -> t3 -> t3'.
|
| So they use the FD globally (when checking use of 'f'), but not local
o:[EMAIL PROTECTED]
| Sent: 24 September 2008 19:27
| To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org
| Subject: Re: GADTs and functional dependencies
|
| >> This has never worked with fundeps, because it involves a *local* type
| equality (one that holds
| >> in some places
Wolfgang writes
| > data GADT a where
| >
| > GADT :: GADT ()
| >
| > class Class a b | a -> b
| >
| > instance Class () ()
| >
| > fun :: (Class a b) => GADT a -> b
| > fun GADT = ()
You're right that this program should typecheck. In the case branch we
discover (locally) that a~(), and he
| 2. But in several places DoCon has parasitic additions
|(similar to the below MulSemigroup (Fraction a))
|to the context for overlapping instances.
|These places are marked in the docon-2.12-pre source with
|'overlaps in ghc'.
|I would like to cancel them, similar as we now
Friends
This is a message for people who use RULES, to ask your opinion. Have a look at
http://hackage.haskell.org/trac/ghc/ticket/2600
and add your comments if you want. The intro to the ticket appears below, so
you can get an idea of whether you are interested.
Simon
Roman writes:
itchell, Neil
| Sent: 17 September 2008 15:38
| To: Jost Berthold; Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: Adding (some) libraries to a GHC tree
|
| Hi Jost,
|
| It looks great now.
|
| When I saw the contributed documentation I did wonder if that was the
| GHC sanc
| Cc: Jost Berthold; glasgow-haskell-users@haskell.org; Simon Peyton-Jones
| Subject: RE: Adding (some) libraries to a GHC tree
|
| Mitchell, Neil wrote:
| > Hi
| >
| > The paragraph in the new page is better than the old one, but it makes
| > sense to have the information in only one place
good stuff -- but with a big overlap with the "Getting more packages" section
in http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources. Do you
agree? Would it be possible to merge your new paragraphs into the existing page?
If the existing page is too big and hard to navigate we c
Why not grab a binary distribution?
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani
| Sent: 17 September 2008 10:35
| To: Simon Marlow
| Cc: glasgow-haskell-users@haskell.org
| Subject: making Happy-1.17
|
: Mitchell, Neil [mailto:[EMAIL PROTECTED]
| Sent: 15 September 2008 13:56
| To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org
| Subject: RE: GADT problems
|
| > | > | (case undefined of Foo GadtValue -> ()) :: () -- is rigid
| > ...
| > |
| > | But the first compiles fine, so
On Sunday 14 September 2008 20:27:52 Mariusz Przygodzki wrote:
> Maybe "they" were waiting so many years because "they" have never
> asked users about what users really need and think about it.
What?
> "It's not that we hate you (unless we do). It's just that we have
> nothing to offer you, and y
| A possibly related question is whether you would expect to make record
| selectors and updaters work for all record types at the same time? That
| would definitely be very useful.
I'm not sure what you mean by this. Would you care to elaborate?
Simon
___
Thanks very much Neil; we (well Ian!) will digest your efforts.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Mitchell, Neil
| Sent: 09 September 2008 14:56
| To: glasgow-haskell-users@haskell.org
| Subject: RE: Window
| Section 8.3.5 of the documentation says:
|
|Arrow notation (see Section 8.9, “Arrow notation ”) uses whatever arr,
(>>>),
|first, app, (|||) and loop functions are in scope. But unlike the other
|constructs, the types of these functions must match the Prelude types very
|closely.
Wolfgang
You need to say that type "t", the case scrutinee, has. You can use a type
signature for that.
Presumably the way that a' is instantiated doesn't matter, but GHC isn't clever
enough to realise that. So I just instantiated it to ().
The result compiles fine.
Simon
{-# LANGUAGE Rank
| Yes this means that Cabal is less general than autoconf. It was quite a
| revelation when we discovered this during the design of Cabal - originally
| we were going to have everything done programmatically in the Setup.hs
| file, but then we realised that having the package configuration availab
| So Cabal takes the view that the relationship between features and
| dependencies should be declarative.
...
| The other principle is that the packager, the environment is in control
| over what things the package 'sees'.
...
| that we can and that the approach is basically sound. The fact that w
| I think we're all rather excited about seeing this stuff land.
| What's the expected timeline, wrt. ghc 6.10's release?
Good question. I've updated the overview here
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen
to say what we plan.
Simon
___
| > Has there been any thought about working with the LLVM project? I
| > didn't find anything on the wiki along those lines.
|
| I have only had a rather brief look at LLVM, but my understanding at
| the moment is that LLVM would not be able to support one of GHC's
| current code layout optimisati
Friends
There's been quite a bit of discussion about GHC's build system recently, and
in particular about the use of Cabal. Responding to that discussion we now
have a new plan, described here:
http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem
If you've taken an interest in
Norman, John
Would you care to respond to this? (Perhaps by amplifying the wiki page?) A
good starting point is perhaps Craig's paper.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Chad Scherrer
| Sent: 22 August 2008 22:21
| To: GHC User
| FWIW, I started a wiki page that tries a direct comparison between
| Darcs and Git:
|
|http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers
Very helpful thank you!
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.or
Suggestions like this are a great help for improving the user manual. Thank
you. I will fix.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-
| [EMAIL PROTECTED] On Behalf Of Yitzchak Gale
| Sent: 12 August 2008 16:48
| To: Simon Peyton-Jones
| Cc: GHC
Friends
| > I see more and more workarounds for workarounds for an unmaintainable
| > (and unusable) build system, and after the latest discussions about
| > git vs. darcs, maintaining GHC-specific branches of libraries etc.,
| > I think I'll just drop maintainership from all GHC-related OpenBSD
|
| It is worth pointing out that I *never* validate against ghc head when
| I commit to the core libraries.
I think that's perfectly reasonable for the reasons you explain.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
ht
Friends
The use of flags to control rewrite rules in GHC is very confusing. Several
bug reports arise from this. There is a summary here:
http://hackage.haskell.org/trac/ghc/ticket/2497
The final comment is a proposal, which I append below. This email is just to
allow others to comme
* Claus is right to say that you want the *renamed* tree, not the *parsed* tree.
* He's also right to point to the under-development generic programming stuff
for the GHC API. I'm not certain about how settled they are right now though.
* But in fact you can get exactly what you want from the m
memory is failing me. Dimitrios or
Stephanie may have a better memory.
Simon
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dagit
Sent: 29 July 2008 15:14
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subject: Re: GHC 6.6 GADT type unification vs GHC 6.8
On Tu
GHC 6.6 was a bit more generous than GHC 6.8, but erroneously so.
Specifically, GHC 6.8 and all subsequent versions require that when you pattern
match on a value of GADT type,
* the type of the scrutinee
* the type of the result of the case
* the types of any free va
Conal
That looks like a bug, at least on the surface. You've clearly said that the
instance for InnerSpace (u,v) can assume (Scalar u ~ Scalar v).
Can you spare a moment submit a Trac report, with a reproducible test case (as
small as possible, please!)?
Manuel is actively working on associat
| giving up. Admittedly I only have a superstition that this will be a
| practical problem.
I agree with Roman -- let's not bother with lenience until we need it
| > Secondly, I think it is quite
| > important to be able to specify dependencies for already declared phases.
| > That is, I (probabl
| > This is the second time I have seen someone comment on implicit
| > parameters being planned for removal, so now you have my attention :).
| > I'd like to mention that a rather large project where I work (Galois,
| > Inc.) uses implicit parameters a lot, so removing support for them
| > would
Yes, the idea of some kind of backtracking solution of class constraints
(multiple instance declarations, choose the one whose context is indeed
soluble) has often been suggested, and is quite attractive. But it raises a
bunch of new complications. And your proposal does so even more, because
| However, if I had to pick something out of the air, I'd say this: always do
| SAT when the argument in question is a function.
Yes, that might well be a good heuristic to try, if you are interested to
pursue this, Max. Making the function static means that it may be inlined, and
that can make
| maybe you can suggest a global flag setting that avoids too much
| inlining during optimization.
As I said to Serge, I *think* all this arises from the *unconditional* inlining
of instance declarations, which isn't under flag control unfortunately. The
only fix at the moment is to write inst
| So, DoCon remains with ghc-6.8.2 -- untill GHC fixes the problem.
|
| Hm ... a small module needs > 600 Mb instead of 80 Mb to compile,
| and the release is considered as a progress.
| All right, this may occur correct -- if the developers know what
| namely must be fixed, and also know how to
Dan
John Dias is indeed spending 6 months at Microsoft to work on GHC's back end.
He's doing a pretty wholesale re-architecting job, so it will be a couple of
months before we have the new setup glued together, but once we do I hope that
we'll have a much more friendly framework in place for d
| Where do I put -fno-ds-multi-tyvar so that the build system knows to use
| it? I'm going to try build.mk.
|
| Ok that didn't work and I couldn't find anything about
| -fno-ds-multi-tyvar in the documentation.
Yes, in GhcLibHcOpts in build.mk is a good place. The flag isn't documented
because i
Might be, but Bryan said that his selectors weren't getting inlined at all,
which is a bit different perhaps
S
| -Original Message-
| From: Isaac Dupree [mailto:[EMAIL PROTECTED]
| Sent: 13 June 2008 12:53
| To: Bryan O'Sullivan
| Cc: Simon Peyton-Jones; glasgow-has
can you give an example? GHC should inline selectors, whether exported or not,
whenever it'd help. They are implicitly defined as INLINE. Since this
obviously isn’t working right, I'd like to see the code. Perhaps you can boil
it down a little, and submit a ticket?
Simon
| -Original Me
Sorry about this -- it's my fault. I did validate a fix to the desugarer, but
ndp isn't part of 'validate'. Turns out that the change to the desugarer
provoked quite subtle and longstanding bug in the simplifier.
To get rolling again, use -fno-ds-multi-tyvar. Or just don't compile NDP. I'll
c
EMAIL PROTECTED] On Behalf Of Conal Elliott
Sent: 09 June 2008 16:28
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subject: Re: desperately seeking RULES help
How does method sharing interact with the ability of the rules engine to "look
through" lets? Wouldn't an f
The -fno-method-sharing flag was supposed to be a bit experimental, which is
why it takes the cheap-and-cheerful route of being a static flag. (Only
dynamic flags can go in OPTIONS_GHC.)
What it does is this. When you call an overloaded function f :: C a => a -> a,
in a function
g = ...f...f..
Richard
I'm assuming you have ready the GHC manual?
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion
Yes, mutually recursive modules are fine (in GHC anyway), and should work as
advertised there. Please do produce a test case if not.
Thanks
Si
601 - 700 of 1599 matches
Mail list logo
