RE: Having trouble with parallel Haskell

| > The most substantial problem is that the threaded RTS in GHC 6.8.2 is | > very crashy in the face of "par": about 90% of my runs fail with a | > segfault or an assertion failure. Simon Marlow mentioned that this bug | > is fixed, but I've been unsuccessful in building a GHC 6.8.3 release | > c

RE: ANNOUNCE: GHC 6.8.3 Release Candidate

Interesting * I think it is a Bad Idea for an application to assume that the implementation of (f^n) will not multiply by 1. Implementations of numeric algorithms probably make all sorts of ill-documented assumptions about the algebraic properties of numeric operations * On the other hand

RE: GHC rewrite rules pragma

| This is the main wibble people forget when writing rules -- inlining. | In your example, 'gen' is so cheap, it is immediately | inlined, so it won't be available to match on in your rule. I'll add a note in the user manual about this. In general, GHC tries RULES before inlining. In this parti

RE: Recursive functions and constant parameter closures (inlining/strictness analyzer question)

| main = print $ foldl' (+) 0 [1..] | | with | | foldl' f y xs = foldl' y xs | where foldl' y [] = y | foldl' y (x:xs) = foldl' (f y x) xs | | runs indefinitely with very little memory consumption, while | | foldl' f y [] = y | foldl' f y (x:xs) = foldl' f (f y x) xs | | rapidly c

RE: bug in 6.8.2?

| class BufferData a where | write :: OutStream -> a -> IO () | | there is writeAll procedure which uses this `write` and therefore | should be able to write any BufferData instance: | | writeAll receiveBuf sendBuf cleanup x = | bracket (create receiveBuf sendBuf cleanup) (closeOut) | (\bu

RE: laziness, memoization and inlining

To: Scott Dillard | Cc: Simon Peyton-Jones; Don Stewart; glasgow-haskell-users@haskell.org | Subject: Re: laziness, memoization and inlining | | Scott Dillard wrote: | > Simon, Don, | > | > You're right. -fno-state-hack fixed it. I've opened a trac ticket. | > Program and t

RE: laziness, memoization and inlining

Scott | I'm experiencing some undesirable performance behavior, I suspect from | inlining things that shouldn't be, defeating my memoization attempts. This is bad, very bad. I think Don is right. I believe the following is happening. In your main program you have do let mesh = memoMesh r

RE: Performance: Faster to define a function writing out all arguments?

| > Anyway, as I am still wondering why ghc creates different code for | > returnP a = return a | > returnP = return | > | | Ah, now I rember this coming up before. | | Simon, is this a CAF issue? Or did it trigger the -fno-state-hack case? I'm not sure. A small example would be good. | I've

Warnings about unused variables or imports

[Moving to GHC users: this thread concerns GHC's warning messages about unused things.] | But there are a few other inconvenient behaviors related only to | warnings, for instance | | module A where | foo x = x | | module B(foo) where | import A | | module C (module A, module B) where | import A

RE: instance export decls

Indeed! I think it'd be good to allow type signatures, including instance signatures, in export lists module Foo( data T (f :: * -> *), instance Functor f => Eq (T f), g :: T f -> T f ) The first step is to evolve a well-worked-out design. I think that'd be a very valu

RE: Optimisation of unpackCString#

| One of my ideas was some RULES that expand: | | test x | "neil" `isPrefixOf` x = ... | | "ned" `isPrefixOf` x = ... You might want to be careful about this, because you could really get a *lot* of code this way. | Simon: I will email you in a couple of weeks to discuss it. Great, th

RE: Unexpected lack of optimisation

| The situation in Neil's code is almost identical, except that the | top-level case expression is on a value passed by environment, not by | function argument. Interesting thought. I think you're describing a possible extension to the SpecConstr transformation described in "Call pattern special

RE: Unexpected lack of optimisation

| It worked, with: | | {-# INLINE [1] begin1 #-} | {-# INLINE begin2 #-} | | I don't think this approach will compose particularly well, and in the | real case I was trying (not this reduced example) I don't think it | will work because there is some recursion and RULES involved. I'll | have anothe

RE: Unexpected lack of optimisation

| {-# INLINE foo #-} | foo = large | | bar x = if x then res else res | where res = foo | | By putting an INLINE on foo I am able to persuade it to be inlined | into the binding of bar, but I can't then persuade it to be inlined at | the let expression. I'm not certain what you mean here. I t

RE: Optimisation of unpackCString#

| > PROPOSAL 1: Add the following rules to the simplifier: | > | > > case unpackCString# "" of ==> case [] of | > > case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of | | I've been wanting to have a go at hacking GHC for a while, and this | seems like a good candidate to star

RE: Optimisation of unpackCString#

| I could imagine adding two rules to the simplifier: | | case unpackCString# "" of ==> case [] of | case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of ... | This goes back to an old gripe of mine actually -- we can't get | at the length of a C string literal at compile time ei

RE: Unexpected lack of optimisation

Neil A nice example, but I think it's difficult to give systematic solution. * The 'retry' function is a "join point", where two different conditional branches join up. * As you say, if 'retry' was inlined, all would be fine. But what if 'retry' was big? Then we'd get lots of code duplication

RE: [Haskell] How to define tail function for Even/Odd GADT lists?

[Redirecting to ghc-users] You're right that tailList "ought" to work. There are at least two reasons that it doesn't. First, GHC does not have a robust implementation of GADTs + functional dependencies. The interaction is very tricky. So I tried re-expressing it using type families, thus:

RE: Error Interpreting Main with API

| Would it also be appropriate to modify that wiki page to reflect some of | the changes between 6.6.1 and 6.8.2? I don't mind doing this at some point | today or tomorrow... Yes please, that would be vv helpful. S ___ Glasgow-haskell-users mailing list

RE: Error Interpreting Main with API

| > The GHC API is behaving just like --make: it links the program if you | > have a Main module. To ask it not to link, you want to do the same as | > '--make -c', which in the GHC API means setting the ghcLink field of | > DynFlags to NoLink. | | Thanks, this has solved the problem I was having.

RE: 6.8 unable to derive with higher-kinded variable (6.6 could)

| GHC 6.8 seems unable to derive (some?) instances for data types with | higher-kinded variables. GHC 6.6 manages these just fine. See below. | data T w = T (w Bool) deriving (Show) | data ID x = ID x deriving (Show) | main = print (T (ID False)) Look at the instance declaration you'd get

RE: Using GHC API to generate STG

LNull is a constructor, so it has no definition in STG. How might it be defined? LNull = ??? Instead, the code generator takes the list of data types (TyCons) as well as the list of bindings. From the former it generates all the per-data-type goop, including info tables for its const

RE: [GHC] #2153: GHCi does not have a :source command to load further .ghci files

| Wow, that simple??? | | What needs to be done to get this in ":?" output? (It should be in the | manual, at least...) Indeed! But it's more application-note than user manual. Fortunately, we have a place for such material, namely GHC's "collaborative documentation" (a wiki) http://

RE: simple CSE?

Not reliably, no. GHC's current CSE is rather opportunistic: we take the opportunity if it's presented in the form let x = e in let y = e in A proper CSE pass would be a nice, containable, project. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott Sent: 29

RE: flexible contexts and context reduction

could get a Show a and Ix b dictionaries from an Ord (a,b) dictionary. (But not an Ord a or Ord b one.) S | | Ganesh | | -Original Message- | From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED] | Sent: 27 March 2008 09:05 | To: Sittampalam, Ganesh; 'Tom Schrijvers'; Ganesh Si

RE: flexible contexts and context reduction

Why "unfortunately"? Looks fine to me. Simon | | Unfortunately, GHC accepts the following: | | {-# LANGUAGE FlexibleInstances #-} | module Foo2 where | | data Foo = Foo | deriving Eq | | instance Ord (Foo, Foo) where | (Foo, Foo) < (Foo, Foo) = False __

RE: flexible contexts and context reduction

| >> To use bar, you need (Ord a, Ord b). You're assuming that Ord (a, b) | >> implies that, but it's the other way round. | | Logically, the implication holds. There's an equivalence: | | Ord a /\ Ord b <=> Ord (a,b) | ... | The problem with dictionaries is that you have to store the supe

RE: Optimization beyond the Module Border

| Would it be possible for the compiler to say something like: "You are | applying level 2 optimization but some dependencies where compiled without | optimization enabled. To get full optimization, consider recompiling x,y,z | with -O2" - at least this would give us a fighting chance to 'fix' thin

RE: Optimization beyond the Module Border

| > I'd be interested in any progress here -- we noticed issues with | > optimisations in the stream fusion package across module boundaries | > that we never tracked down. If there's some key things not firing, | > that would be good to know. | | I suspect that if all modules are compiled -O0, the

RE: Optimization beyond the Module Border

| I have noticed that there is a great difference between optimizing | modules separately and all at once, e.g., with -fforce-recomp. I have | had examples factors up to 15 in run time (and even different behavior | in context with unsafePerformIO). GHC does a lot of cross-module inlining already,

RE: monomorphic or not?

| On Thu, Mar 06, 2008 at 08:56:15AM +, Simon Peyton-Jones wrote: | > No, it's fine. compress is indeed monomorphic, but since it's called | > at exactly one type, namely Char, so it gets the monomorphic type | > [Char] -> [Char]. That is what the Haskell Report

RE: scope of header files

If, following this thread, you conclude that GHC should do something different than what it does, can you submit a Trac ticket? With a small example? Thanks S | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Duncan Coutts | Sent: 06 March 2008 00:

RE: monomorphic or not?

No, it's fine. compress is indeed monomorphic, but since it's called at exactly one type, namely Char, so it gets the monomorphic type [Char] -> [Char]. That is what the Haskell Report says. (Or tries to.) Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

RE: STM and fairness

| I'd like to know a bit about the STM implementation in GHC, | specifically about how it tries to achieve fairness. I've been reading | "Composable Memory Transactions" but it does not contain that much | details on this specific matter. What I want to know boils down to | this: what order are pro

RE: static constants -- ideas?

| On another note, I am extremely curious about the difference | between statically compiling a list and building it at | runtime. I find it hard to wrap my head around the fact that I | can build the list at runtime in a short time, but can not | compile it without eating all of my machi

RE: ghci feature request: partially read modules

That's a fair suggestion. (With the subsequent clarification about getting through the parser and renamer first.) Would you like to check the open feature requests (in case it's there already) and add it as a feature request? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailt

RE: Shared Libraries in ghci

Any chance of documenting your experience on the GHC user documentation page? http://haskell.org/haskellwiki/GHC (under "collaborative documentation") A kind of how-to that worked for you, with pointers to relevant manual parts etc. Simon | -Original Message- | From: [EMAIL PROT

RE: Will implicit parameters survive?

I don't have any active plans to remove implicit parameters. I think they are not heavily used, but for those that do use them they seem to be quite helpful, and (important for me) their effect on the compiler is quite localised, so they cause little trouble. Still, I'm always interested to kn

RE: GHC lazy eval optimization bug

| Thank you for the explanation. Inlining does explain the behavior I | was seeing, and -fno-state-hack does make the program behave the way | I'd expect. | | I would like to humbly submit that perhaps this optimization should be | off by default. I agree that the current behaviour sometimes bite

Internships at GHC HQ

Would you be interested in working at Microsoft Research for three months? If so, you might want to think about applying for an internship. Simon and I are looking for interns, starting in summer 2008. Lots of background info here: http://hackage.haskell.org/trac/ghc/wiki/Internships i

RE: instance overlap

Serge, and others | 1. Can you check what ghc-5.02.3 will report on the below small program |with DShow I don't have ghc 5.02 to hand, but here's what 5.04.3 says about the code you give. ghc-5.04.3 -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances Serge.hs Serge.

RE: gmp

| > gmp is nice, it is really convenient. But someone needs | > to completely clarify the license issues in that case, and | > make it completely clear to all users. | | I completely agree that we need to document the situation clearly. Although I hate discussing licensing (which is why GHC has a

RE: GHC Data.List.sort performance question

Weird. I see no difference in the compiled code (GHC HEAD). Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Marcus D. Gabriel | Sent: 14 January 2008 21:02 | To: glasgow-haskell-users@haskell.org | Subject: GHC Data.List.sort performance ques

RE: GHC Internals Changed

Probably not, or at least not well. I'm afraid you'll just have to look at the new API and ask questions. Putting what you learn on the Wiki is a great service for others who walk the same path. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf O

RE: problem with GHC installaion on x86_64

This is a fixed bug http://hackage.haskell.org/trac/ghc/ticket/2011 However I hadn't realised that it's in 6.8.2; I thought we'd fixed it prior to the 6.8.2 release. The workaround is simple: do a "make clean". (That's why our tests didn't pick it up; they all start from clean.)

RE: Rank-2 polymorphism and pattern matching

Jim | My reason for wanting pattern matching on values of polymorphic types | is a kind of first-level refinement types. I'm going to demonstrate | using the "risers" function, as presented in Dana N. Xu's ESC/Haskell, which | references Neil Mitchell's Catch. I didn't follow all the details, but

RE: GHC Core question

If you use -dppr-debug GHC will show you the unique number of each identifier, and that'll show you that the two $dMonads are distinct even though they have the same print-name. CoreTidy makes the print-name unique too. Perhaps the Core printer should be a bit keener to print unique numbers, bu

RE: Rank-2 polymorphism and pattern matching

| > The following won't compile for me | > | > isnull :: (forall a . [a]) -> Bool | > isnull ([] :: forall b . [b]) = True | > | >Couldn't match expected type `forall b. [b]' | >against inferred type `[a]' | > In the pattern: [] This is a pretty strange thing to do, to match a

RE: Redefining built in syntax

| C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts | -package-name base | GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help | | :1:22: | Failed to load interface for `System.IO': | it is not a module in the current program, or in any known package. I don

RE: GHC source code improvement ideas

Twan, In general I'd be delighted for you to clean up GHC's code -- thank you! There is a slight down-side which is that because you end up touching a lot of code, you get a big patch that means you can't selectively pick patches from before and after the change -- but I'm not too bothered abo

RE: <.> defined in GHC and System.FilePath

I've no objection to renaming it, if that's more convenient. It's a kind of composition operator, hence the name. Perhaps <:>? By all means send, or commit, a patch Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Neil Mitchell | Sent: 31

RE: whole program optimization

| Am Sonntag, 23. Dezember 2007 13:35 schrieb Isaac Dupree: | > GHC optimizes less effectively when parts of a program are in different | > modules, or are exported from a module. | | By the way, does GHC do cross-package optimization (not just cross-module | optimization within packages)? GHC doe

RE: GADT pattern match in non-rigid context

| >> You should be giving a type signature to rewrap! That should fix it. | > | > Thanks, all works fine now :-) | | it would be great if the error message suggested giving a type signature | as a solution (or maybe it already does, in the HEAD?) Good point: I'll do that. Simon | >> | -Ori

RE: whole program optimization

The GHC API ought to make this relatively easy, but sadly doesn't at the moment. What you'd want: - read in each module in turn, typecheck, desugar, perform modest simplification, and keep the resulting Core bindings - now glom all those bindings together and optimize - code generate, write out

RE: GADT pattern match in non-rigid context

You should be giving a type signature to rewrap! That should fix it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Neil Mitchell | Sent: 17 December 2007 16:23 | To: glasgow-haskell-users@haskell.org | Subject: GADT pattern match in non-rig

RE: Hugs faster than GHC

It's a perf bug in 6.6, happily fixed in 6.8.1 Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Bernd Brassel | Sent: 14 December 2007 12:59 | To: glasgow-haskell-users@haskell.org | Subject: Hugs faster than GHC | | The following program revea

RE: newtypes and optimization

| However when I do this: | | > newtype Quaternion = Q (Vec4 Double) | | Everything is ruined. Functions like peek and vadd are no longer inlined, | intermediate linked lists are created all over the place. The Quaternion | Storable instance looks like this Turns out this is a perf bug in 6.8 that

RE: [Haskell-cafe] class default method proposal

| If it really would work ok we should get it fully specified and | implemented so we can fix the most obvious class hierarchy problems in a | nice backwards compatible way. Things are only supposed to be candidates | for Haskell' if they're already implemented. Getting it fully specified is the f

RE: Encoding Lists with Lengths by Type Family

I've typechecked this by hand, and indeed it looks to me as if it should work. (Admittedly, your inAssocL function is making an unsubstantiated claim (since you define it as 'undefined'), but that is still sound since any attempt to run the program will diverge. But it should tpyecheck.) Here

RE: Strange compilation behavior

| I'm using ghc 6.6.1 under Ubuntu Gutsy on a Pentium 4 machine, and I | was working to get some code running in an acceptable time. I was | surprised to find that turning on profiling switches made the code run | over 40x faster! That is indeed strange. Things to try: * Try without -O. * Try w

RE: type equality symbol

| > Nothing deep. Just that "=" means so many things that it seemed better | > to use a different notation. | > | | How about ==? Only one meaning so far, and that both on the term level and | equivalent to the constraint I'm quite happy with "~"! It's sufficiently different from "=" that someon

RE: type equality symbol

kell-users@haskell.org; Simon Peyton-Jones | Subject: type equality symbol | | >>conv :: (a~b) => a -> b | >>conv = id | | is there any particular reason that '~' is the symbol for type equality | constraints? I would think '=' would be the o

RE: fundeps help

| I did originally intend to try all this with the | HEAD, but one obstacle to this is the lack of recent linux | binaries in http://www.haskell.org/ghc/dist/current/dist/ Ian is fixing that. We'd missed the fact that the bindists weren't being built. Hold on a day or two. Simon ___

RE: fundeps help

| > And here we know that y=Bool; yet since we don't write the type sig | > directly we can't say it. So GHC's implementation of fundeps rejects | > this program; again it can't be translated into System F. | | Conveniently, this is a good example of my other problem with fundeps :-) | I can work

RE: GHC generated dll makes Excel crash on exit.

into the wiki). If not, let's see why not. It'd be better to put your new material in with the other FFI stuff; it'll be easier to find that way. THanks SImon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Boudry Sent: 03 December 2007 14:28 To: Simon Pe

RE: fundeps help

| Is it really a good idea to permit a type signature to include | equality constraints among unifiable types? Does the above type | signature mean something different from a ->a? Does the type signature: | foo :: (a~Bar b) => a -> Bar b | mean something different from: | foo :: Bar b

RE: fundeps help

| I'm trying to understand what fundeps do and don't let me do. One | particular source of confusion is why the following program doesn't | typecheck: | | {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} | module Fundeps where | | class Dep a b | a -> b, b -> a | | conv :: (Dep a b1,D

RE: win32&ghc: using more than 2gb of memory

GHC definitely does not assume that the top bit is of an address is clear. But I don't know that anyone has explicitly tested it on a 3Gb program. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Bulat Ziganshin | Sent: 02 December 2007 14:12

RE: GHC generated dll makes Excel crash on exit.

Better still, could you add a section to that page about DLLs and Excel? That'd be useful for others. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Boudry Sent: 30 November 2007 18:09 To: glasgow-haskell-users@haskell.org Subject: Re: GHC generated dll makes Excel

RE: suggestion: add a .ehs file type

| So, my suggestion is that in any case where the compiler currently | suggests use of a particular pragma in an error message, it should | instead turn that pragma on and produce a warning. In the cases where the compiler makes that suggestion, yes what you suggest would be feasible I think. Bu

RE: label syntax vs DisambiguateRecordFields

| Nice feature but feel like a band-aid. In particular it makes SYB style | programming more difficult because field labels aren't types. | | Almost every other record syntax plan involves field labels as types so | you can do interesting type dispatch. Record systems are indeed an interesting ar

RE: suggestion: add a .ehs file type

Alex, | Ok, I'm game to default to haskell98 in the presence of ambiguity, but | in most cases the extension involves new syntax and that should be enough. Trying to compile the program both ways (or 2^n ways) to check for ambiguity sounds like a pretty heavy hammer to crack this nut. GHC is a

RE: suggestion: add a .ehs file type

| So what is DisambiguateRecordFields? It's documented in the user manual (for the HEAD): http://www.haskell.org/ghc/dist/current/docs/users_guide/syntax-extns.html#disambiguate-fields Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell- | [EMAIL PROTECTED] On B

RE: The order if bindings generated by GHC

You probably want -ddump-simpl to print Core Yes, the bindings should be in dependency order. They certainly seem to be for me Simon Foo.hs data Numeral = Zero | Succ Numeral zero = Zero one = Succ zero ten = Succ one ghc -c -ddump-stg -ddump-simpl Foo.hs Tidy Core ===

RE: State of parallel GC?

Using concurrency in GC usually implies one of - Parallel GC. Stop the mutator(s) and use multiple processors to do GC; when they are done, start the mutators. This isn't real-time, because there's an unbounded pause for GC. This is what Simon and Roshan's parallel collector does. - Interle

RE: GHC 6.8.1 SpecConstr

Urk. Well spotted! I omitted a prime (writing env instead of env') in a late fix, and as a result practically no top-level rules and specialisations are being applied. What an egregious bug. The good news is that a one-character fix should make 6.8.2 perform quite a bit better than 6.8.1! Sim

RE: Top-level bindings for unlifted types

What would you expect to happen for this? fib :: Int -> Int# fib n = ... x :: Int# x = fib 100# 'x' cannot be bound to a thunk. So the top-level computation would have to be evaluated eagerly. But when? Perhaps when the program starts? Maybe one could do that, but we have not done so. To

RE: Extensible Records

| There seems to be widespread agreement that the current situation wrt | records is unacceptable, but the official GHC policy is that there are too | many good ideas to choose from - so nothing gets done! I hence humbly | propose that [http://www.cs.uu.nl/~daan/download/papers/scopedlabels.pdf

RE: ANNOUNCE: GHC version 6.8.1

| That's not a problem in GHC's configure.ac or other .ac files. It's just If it's nothing to worry about, and has a sensible explanation, can someone add it to the Building GHC FAQ? (If this page doesn't exist, it ought to!) Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto

RE: GHC 6.8.1 is impressive!

O2 mainly switches on two transformations: "liberate case" and "call-pattern specialisation". (I think it also gets passed on to gcc.) Trying -O2 -fno-liberate-case, and -O2 -fno-spec-constr might tell which was making the difference. Simon | -Original Message- | From: [EMAIL PROTECTE

RE: GHC 6.8.1 is impressive!

| In that case, the 33% I cite above includes constructor | specialization, since we compile with -O2 anyway. I just wasn't sure | that it was in since it wasn't called out in the release notes. Probably because it was in 6.6 too, only less polished. | On | that topic, does anyone know a clever w

RE: GHC 6.8.1 is impressive!

| I just finished a running Bluespec's regression suite on a version of | our tools compiled with ghc 6.8.1. The results were impressive on two | fronts: | | 1. All of our tests (almost 14,000) had the same behavior as with ghc 6.6.1 | 2. Our Haskell code was roughly 33% faster (relative to ghc 6.6

RE: Getting source code

I've updated the "Getting the GHC sources page" -- you might want to check I got it right. http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources In general, though, yes it's a Wiki and you are not only welcome but positively encouraged to make it more helpful. So go right ahead.

RE: Building a prelude

You probably need to compile with -package-name base. When you compiled Err.lhs-boot you need to say that it belongs to package base. S | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Victor Nazarov | Sent: 07 November 2007 14:28 | To: glasgow-has

RE: Template Haskell documentation

The current documentation is laughably sparse. Documentation patches would be hugely welcomed. Thank you! Alfonso is also working actively on TH at the moment. I'm ccing him Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Richard Giraud |

RE: Why only inference in type checking?

orking on a system that support both general top-level equations and arbitrary local constraints. Simon | -Original Message- | From: Philip K.F. Hölzenspies [mailto:[EMAIL PROTECTED] | Sent: 19 October 2007 09:38 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Sub

RE: Generalized newtype deriving 6.6 vs. 6.8

Well it's debatable. Suppose we have newtype Foo = MkFoo String deriving( Num ) Do you want to generate instance Num String => Num Foo ? I suspect not -- usually we generate an error message right away if we need a Num String instance and one is not available. Now you could argue that |

RE: confusing GADT/scoped type variables behaviour

Ganesh Sorry to be slow on this. Thanks for the bug report. | Now 6.6 is happy. But 6.8 doesn't believe they are the same, and rejects | it. I finally got it to work with both by removing the forall in the | So, is there a good explanation of the errors from 6.8? Is 6.8 behaving | as expected?

RE: Too many local registers...

We are working on a substantial re-engineering of GHC's code generation, so this problem will eventually go away. But think "2008" not "Christmas 2007". Meanwhile does -fasm work? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Duncan Cout

RE: Case of "Language" pragma - bug?

| "Pragmas all take the form {-# word ... #-} where word indicates the type of | pragma, and is followed optionally by information specific to that type of | pragma. Case is ignored in word." | | However, when I use "Language CPP" instead of "LANGUAGE CPP" in the pragma, | the pragma is ignored. I

RE: kind error

I don't see how that could *ever* have compiled. >From MinHeap: data Min h a = E | M a h deriving (Eq) >From UnbalancedSet: data Set a = E | T (Set a) a (Set a) So the type synoynm for FastClasus is ill-kinded, as GHC says. Simon | -Original Message- | From: [EMAIL

RE: type families not advertised for 6.8

unexpected interaction that I have yet to sort out! http://hackage.haskell.org/trac/ghc/ticket/1496) Simon | -Original Message- | From: Remi Turk [mailto:[EMAIL PROTECTED] | Sent: 20 October 2007 21:25 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org; Jean-Philippe

RE: type families not advertised for 6.8

| | > Of course none of this is implemented! | | But it all sounds very cool. I would like it. :-) ...and you shall have it :-) Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasg

RE: type families not advertised for 6.8

| But the problem in the HList example is that two equations apply where the | most specific one should be taken. There is no difficulty in principle with this. You just need to state (and implement) the rule that the most specific equation applies. That is, there's no reason in principle you

RE: type families not advertised for 6.8

olfgang Jeltsch | Sent: 19 October 2007 09:51 | To: glasgow-haskell-users@haskell.org | Subject: Re: type families not advertised for 6.8 | | Am Freitag, 19. Oktober 2007 09:25 schrieb Simon Peyton-Jones: | > […] | | > Our current plan is to regard FDs as syntactic sugar for indexed type | &g

RE: type families not advertised for 6.8

| What does this imply for 6.8 support for FD's, as they now use | the same type-coercions? Actually FDs do not use type coercions, in GHC at least. As Mark originally described them, FDs guide inference; and in particular, they give rise to some unifications that would not otherwise occur. In

RE: Why only inference in type checking?

| For actual arguments of f, there is no issue whatsoever with | decidability. The type checker in my brain uses unification, i.e. | top-down. The type checker in GHC uses inference, i.e. bottom-up. Why | inference potentially suffers from non-termination for this program, I | understand. Actually

RE: ANNOUNCE: GHC 6.8.1 Second Release Candidate

| - the list of outstanding issues for 6.8 branch is suspiciously long. has | this been reviewed in detail? Good point, Claus. Lots of people are using GHC for lots of things. This is a nice problem to have! But it does lead to lots of bug reports. We have limited resources, so we have t

RE: type families not advertised for 6.8

| > Absolutely not; quite the reverse. It means that some of the *code* for | type functions happens to be in the 6.8 release --- but that code has bugs. | It's only in 6.8 for our convenience (to avoid too great a divergence between | the HEAD and 6.8), but we do not plan to *support* type functi

RE: type families not advertised for 6.8

| on I read: “we are | not advertising type equalities for 6.8”. What does this mean? Is it | possible that type family support will be removed from GHC at some point? Absolutely not; quite the reverse. It means that some of the *code*

<    3   4   5   6   7   8   9   10   11   12   >