Hi,
I was going to do some hacking on Haddock. Haddock depends on the GHC API from
the development version of GHC, however, stage2 crashes on my system when I try
to build the newest GHC from the repository. Since I don't actually need to
compile with the new GHC, I'm hoping there's a workar
I'm curious about global constant propagation in GHC. It's a fairly basic
optimization in the CFG-based compiler domain, and it's similar to constructor
specialization, but it doesn't seem to be in GHC's repertoire. Perhaps it's
usually subsumed by other optimizations or it's more complicated
s 'fooName' does not.
> Date: Mon, 2 May 2011 23:03:23 -0300
> Subject: Re: Elimination of absurd patterns
> From: felipe.le...@gmail.com
> To: red...@hotmail.com
> CC: glasgow-haskell-users@haskell.org
>
> On Mon, May 2, 2011 at 6
I'm re-sending this e-mail, hopefully with proper line breaks this time.
I was experimenting with using GADTs for subtyping when I found something
interesting. Hopefully someone can satisfy my curiosity.
Here are two equivalent GADTs. My understanding was that GHC would translate
"Foo" and "
I was experimenting with using GADTs for subtyping when I found something
interesting. Hopefully someone can satisfy my curiosity.
Here are two equivalent GADTs. My understanding was that GHC would translate
"Foo" and "Bar" into isomorphic data types. However, GHC 6.12.3 generates
better cod
Hello,
I'd like to know how ghc-pkg searches package databases and how the
command-line flags affect the search.
My model of ghc-pkg was that it builds a list of package databases and then
searches them starting from the head. I'd like to work with a sandboxed local
package database. Lookin
(Hotmail is again swallowing newlines--sorry for the re-post)
I see. The type inference algorithm requires type variables to be
type constructors, not functions. Equality constraints are
simplified assuming that is the case. I knew that type
functions had to be fully applied, but I didn't know
I see. The type inference algorithm requires type variables to betype
constructors, not functions. Equality constraints aresimplified assuming that
is the case. I knew that typefunctions had to be fully applied, but I didn't
know that they alsocouldn't be "taken apart" by unification. This
I would like help understanding a type error I'm getting with GHC 6.10.4.
GHC reports a type mismatch for the types in a satisfiable equality
constraint. The function "idLazy" below demonstrates the error. I would
appreciate if someone can explain what's going on.
Thanks,
-heatsink
{-# LANGUAG
> Which message do you prefer? I couldn't tell which it was.
I prefer fun1. In my understanding, the 'inferred' type is gleaned by looking
at theexpression itself, while the 'expected' type is implied by the context.
___
(Some formatting was apparently lost en route. Trying again with extra
newlines.)
I came across a type error that misled me for quite a while, because the
expected and inferred types were backwards (from my point of view). A
simplified example is below. Can someone explain how GHC's type che
I came across a type error that misled me for quite a while, because the
expected and inferred types were backwards (from my point of view). A
simplified example is below. Can someone explain how GHC's type checker
creates the error message?
In this example, fun1 and fun2 are basically the s
I've encountered the problem with weak symbols also, and filed a bug report
against ghc (#).
Weak symbols are used by gcc (with elf) to accommodate C++'s compilation model.
In C++, it's permitted to define class methods and template code in header
files. Because header files can be includ
Thanks for the explanation. I see how this wouldn't behave nicely with
automatic class constraint inference. I didn't test the example on any other
GHC versions.
I will probably end up passing in the Eq dictionary from outside like Daniil
suggested. I would prefer to do the following, but G
I discovered that closed type classes can be implicitly defined using GADTs.
The GADT value itself acts like a class dictionary. However, GHC (6.8.3)
doesn't know anything about these type classes, and it won't infer any class
memberships. In the example below, an instance of Eq is not recog
I've "fixed" this problem by increasing the number of registers used on ia64 to
34. The problem will show up again if anyone finds a way to make GCC use even
more registers.
-heatsink
>>
>> Sorry, I couldn't find the rest of the preceding message. Someone
>> wrote that they had to turn dow
The wiki has "edit" links if I login as guest, but not if I login as
heatsink. Is that also because of the spam issue?
_
Get a FREE Web site, company branded e-mail and more from Microsoft Office
Live! http://clk.atdmt.com/MRT/go/
17 matches
Mail list logo