Re: ghc fails hello world on ppc

I forgot to say that the version is 6.0.1. So... can anyone else reproduce this? Is there a stable version of the compiler which I should be using instead? Is there anything I can do to help fix this bug? I've been playing around with PPC Linux a bit on the weekend, and I can't reproduce the

Instances which worked in ghc6.0.1 don't work for developmentsnapshot 6.3.20031201

For ghc6.0.1 on Linux # ghc Test1.hs -c -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances # ghc Test2.hs -c -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances works. But for ghc6.3.20031201 the second compilation produces the message:

Re: ghc fails hello world on ppc

I forgot to say that the version is 6.0.1. So... can anyone else reproduce this? Is there a stable version of the compiler which I should be using instead? Is there anything I can do to help fix this bug? I've been playing around with PPC Linux a bit on the weekend, and I can't reproduce

RE: import modules from a different directory

Anybody has the experience of importing a module from a different directory?In my code, i need to import a module that is not in the current directory. How can I do that in GHC? GHC-specific questions are best asked on [EMAIL PROTECTED] (where I've sent this followup). You'll find the -i

forkProcess type changed?

For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () - IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork if this is the parent

RE: forkProcess type changed?

For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () - IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork if this is the

Re: forkProcess type changed?

On Thu, Dec 11, 2003 at 04:44:37PM +0100, George Russell wrote: In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Isn't it rather IO (Maybe System.Posix.Types.ProcessID) ? Best regards, Tom -- .signature: Too many levels of symbolic links

Re: forkProcess type changed?

George Russell wrote: For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () - IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork

Re: type classes, superclass of different kind

Robert Will wrote: Note that in an OO programming language with generic classes ... (We shouldn't make our functional designs more different from the OO ones, than they need to be.) why should *we* care :-) more often than not, OO design is resticted and misleading. you see how most OO

RE: type classes, superclass of different kind

Robert Will wrote: Now I would like to have Collection to be a superclass of Map yielding the following typing reduce :: (Map map a b) = ((a, b) - c) - c - map a b - c Note that in an OO programming language with generic classes (which is in general much less

Re: type classes, superclass of different kind

--- Robert Will [EMAIL PROTECTED] wrote: -- Here -- is a quesion for the -- most creative of thinkers: which is the design (in -- proper Haskell or a -- wide-spread extension) possibly include much -- intermediate type classes and -- other stuff, that comes nearest to my desire? Hello,

Re: type classes, superclass of different kind

On Thu, 11 Dec 2003, Robert Will wrote: Hello, As you will have noticed, I'm designing a little library of Abstract Data Structuresm here is a small excerpt to get an idea: class Collection coll a where ... (+) :: coll a - coll a - coll a reduce :: (a - b) - b

GreenCard (How to Marshell Int64)

Hello: I am using GreenCard to import some C code into Haskell. The code I want to import uses "long" in a lot of places. I tried to write my own DIS for it andIalso write a very simple test program. However,the DIS does not workproperly. My program and test result are as following:

Re: Preventing/handling space leaks

L.S., On Wed, 10 Dec 2003 09:49:54 -0800, Iavor S. Diatchki [EMAIL PROTECTED] wrote: hello, Henk-Jan van Tuyl wrote: : : So far I have seen only one rule for Good Coding Practice in Haskell: Do Not Use n+k Patterns. I hope someone can give some directions, how to avoid known pitfalls

Re: import modules from a different directory

moved to haskell-cafe Hi, You can give GHC with -iPath a directory where to look for modules. With -v you see where GHC actually looks for libraries. Cheers, Georg On Thu, 11 Dec 2003 15:59:04 +0800 (GMT-8), Wang Meng [EMAIL PROTECTED] wrote: Hi All, Anybody has the experience of

bugs from n+k patterns (was: Re: Preventing/handling space leaks)

hi, first here is why i think n+k patterns are problematic; 1) they lead to some parsing awkwardness (e.g. when n+k pattern bindings are involved, but those don'treally make much sense anyways) 2) in haskell as it is, patterns are associated with algebraic datatypes, and n+k patterns may

Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

On Thu, 11 Dec 2003 06:23:51 -0800 Iavor S. Diatchki [EMAIL PROTECTED] wrote: ... Henk-Jan van Tuyl wrote: ... 2) It is likely, that n+k patterns dissapear in the next Haskell standard. If you don't like to rewrite, test and debug all your software every few years, don't use any

Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

The n+k pattern issue inspired endless debates on the Haskell committee and this feature was considered for removal in nearly every iteration of the Haskell report. We all agreed that n+k is extremely ad-hoc but that certain programs can be expressed slightly more elegantly using them.