RE: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-11-02 Thread Simon Marlow
On 01 November 2005 16:32, Florian Weimer wrote: * Simon Marlow: gcc started generating this rubbish around version 3.4, if I recall correctly. I've tried disabling various optimisations, but can't seem to convince gcc not to generate the extra jump. You don't get this from the native

Array operations and pinning

2005-11-02 Thread Rene de Visser
Hello, Where is the documentation on how pinning works in the GHC garbage collector (from a GHC users point of view). I have copied the following code from array/IO.hs and am thinking that it is assuming that the array is pinned? What triggers the pinning? On a second note. Why is the type

Re: jhc vs ghc and the surprising result involving ghc generated assembly.

2005-11-02 Thread Tony Finch
On Wed, 2 Nov 2005, skaller wrote: On Tue, 2005-11-01 at 19:03 +0100, Florian Weimer wrote: BTW, you shouldn't generate identifiers with leading underscores because they are reserved for the implementation. I AM the implementation :) You are not the C implementation. Generated

RE: Array operations and pinning

2005-11-02 Thread Simon Marlow
On 02 November 2005 11:15, Rene de Visser wrote: Where is the documentation on how pinning works in the GHC garbage collector (from a GHC users point of view). I have copied the following code from array/IO.hs and am thinking that it is assuming that the array is pinned? What triggers the

Re: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-11-02 Thread Florian Weimer
* Simon Marlow: gcc started generating this rubbish around version 3.4, if I recall correctly. I've tried disabling various optimisations, but can't seem to convince gcc not to generate the extra jump. You don't get this from the native code generator, BTW. But the comparison is present

RE: jhc vs ghc and the surprising result involving ghcgeneratedassembly.

2005-11-02 Thread Simon Marlow
On 02 November 2005 13:59, Florian Weimer wrote: However, beginning with GCC 3.4, you can use: extern void bar(); void foo() { void (*p)(void) = bar; p(); } Interesting.. though I'm not sure I'm comfortable with relying on gcc's tail call optimisation to do the right thing.

Re: jhc vs ghc and the surprising result involving ghcgeneratedassembly.

2005-11-02 Thread Florian Weimer
* Simon Marlow: However, beginning with GCC 3.4, you can use: extern void bar(); void foo() { void (*p)(void) = bar; p(); } Interesting.. though I'm not sure I'm comfortable with relying on gcc's tail call optimisation to do the right thing. Aren't there side conditions that

Re: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-11-02 Thread skaller
On Wed, 2005-11-02 at 14:59 +0100, Florian Weimer wrote: Is it correct that you use indirect gotos across functions? Such gotos aren't supported by GCC and work only by accident. Even direct gotos aren't universally supported. Some info in Fergus Henderson's paper may be of interest

Re: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-11-02 Thread Florian Weimer
Is it correct that you use indirect gotos across functions? Such gotos aren't supported by GCC and work only by accident. Even direct gotos aren't universally supported. Some info in Fergus Henderson's paper may be of interest http://felix.sourceforge.net/papers/mercury_to_c.ps This paper

Re: jhc vs ghc and the surprising result involving ghcgeneratedassembly.

2005-11-02 Thread Lennart Augustsson
Simon Marlow wrote: Is it correct that you use indirect gotos across functions? Such gotos aren't supported by GCC and work only by accident. Yes, but cross-function gotos are always to the beginning of a function. Is that enough to ensure that the constant pool base register is reloaded

Re: jhc vs ghc and the surprising result involving ghcgeneratedassembly.

2005-11-02 Thread Florian Weimer
* Lennart Augustsson: Simon Marlow wrote: Is it correct that you use indirect gotos across functions? Such gotos aren't supported by GCC and work only by accident. Yes, but cross-function gotos are always to the beginning of a function. Is that enough to ensure that the constant pool base

Re: jhc vs ghc and the surprising result involving ghc generatedassembly.

2005-11-02 Thread skaller
On Wed, 2005-11-02 at 18:05 +0100, Florian Weimer wrote: Is it correct that you use indirect gotos across functions? Such gotos aren't supported by GCC and work only by accident. Even direct gotos aren't universally supported. Some info in Fergus Henderson's paper may be of interest

Re: jhc vs ghc and the surprising result involving ghc generated assembly.

2005-11-02 Thread skaller
On Wed, 2005-11-02 at 19:47 +0100, Florian Weimer wrote: It seems that the goto-based version leads to different static branch prediction results, which happen to be favorable. It has nothing to do with branch prediction. I know it is determined ENTIRELY by stack use. In both cases,

Silly IO problem

2005-11-02 Thread skaller
This code doesn't work: import System(getArgs) main = do n - getArgs = readIO.head putStrLn (show (tak (3*n) (2*n) n)) tak :: Float - Float - Float - Float tak x y z | y=x = z | otherwise = tak (tak (x-1) y z) (tak (y-1) z x) (tak (z-1) x y)

[Haskell] Haskell Workshop Steering Committee

2005-11-02 Thread Johan Jeuring
At the Haskell workshop in Tallinn in September it was decided to set up a Haskell Workshop Steering Committee. The main purpose of the Haskell Workshop Steering Committee is to provide continuity of the workshop and to offer help and advice to the current organizer(s) of the workshop.

RE: [Haskell] specification of sum

2005-11-02 Thread Simon Marlow
On 02 November 2005 00:20, Lennart Augustsson wrote: Furthermore, ghc has a WRONG definition of sum. Surely not... sum is defined by Haskell 98 as: sum = foldl (+) 0 and this is exactly what GHC provides. Furthermore we have specialised strict versions for Int and Integer. Also, we

[Haskell] why don't we have const Ptrs?

2005-11-02 Thread David Roundy
Hello all, I was thinking this morning as I lay on the floor (where I sleep) about static typechecking, and how much more wonderful Haskell is than any other language, when it occurred to me that when working with pointers, Haskell actually has *less* static typechecking than C or C++. It was a

[Haskell] pattern matching on record fields and position

2005-11-02 Thread David Roundy
Hello fellow haskellers, I have a couple of related (almost conjugate) proposals/questions. Basically, I've been thinking about how to make code more robust with respect to changes in the data types. Pattern matching based on positions is very fragile (I don't think this is a surprise to

Re: [Haskell] pattern matching on record fields and position

2005-11-02 Thread Malcolm Wallace
David Roundy [EMAIL PROTECTED] writes: I have a couple of related (almost conjugate) proposals/questions. Basically, I've been thinking about how to make code more robust with respect to changes in the data types. This sounds a bit like views, proposals for which have been around for years,

[Haskell] The next langauage definition version will be ``Haskell 1.6''

2005-11-02 Thread kahl
Hi all, somebody wrote something which reminds me: * * * The ``next stable version'' of the Haskell language definition * * should be

Re: [Haskell] why don't we have const Ptrs?

2005-11-02 Thread Daan Leijen
Hi David, One could pretty easily create a ConstPtr type which one could peek into, but not poke to, but then you'd have to explicitely convert a Ptr into a ConstPtr when passing it as an argument. That feels a bit silly. One way of dealing with constant pointer is to introduce (yet

Re: [Haskell] why don't we have const Ptrs?

2005-11-02 Thread Bjorn Lisper
Hi, Annotated type systems have been around for some time in static program analysis. I think this is what you want. For instance, you can design such a system to record possible side effects from a function call, as annotations on the type of the function. See the book Principles of Program

Re: [Haskell] why don't we have const Ptrs?

2005-11-02 Thread Josef Svenningsson
Hi, Here's a way to do pretty much what you're after. The idea is to add an extra parameter to the Ptr type to indicate if it is a const pointer or not. data Ptr const a To indicate the constness we create a dummy data type which will show when the pointer type is *not* const. data NotConst

RE: [Haskell] specification of sum

2005-11-02 Thread Scherrer, Chad
Surely not... sum is defined by Haskell 98 as: sum = foldl (+) 0 and this is exactly what GHC provides. Furthermore we have specialised strict versions for Int and Integer. I'd been using ghci for testing along the way and getting terrible results; does the specialization only

Re: [Haskell] specification of sum

2005-11-02 Thread Cale Gibbard
On 02/11/05, Scherrer, Chad [EMAIL PROTECTED] wrote: Surely not... sum is defined by Haskell 98 as: sum = foldl (+) 0 and this is exactly what GHC provides. Furthermore we have specialised strict versions for Int and Integer. I'd been using ghci for testing along the way and

Re: [Haskell] specification of sum

2005-11-02 Thread Lennart Augustsson
Simon Marlow wrote: On 02 November 2005 00:20, Lennart Augustsson wrote: Furthermore, ghc has a WRONG definition of sum. Surely not... sum is defined by Haskell 98 as: sum = foldl (+) 0 and this is exactly what GHC provides. Furthermore we have specialised strict versions for Int and

Re: [Haskell] pattern matching on record fields and position

2005-11-02 Thread John Meacham
You might want to look at the 'get', 'set' and 'update' rules that DrIFT can derive. i made them to addres a lot of the same issues you mentioned. I personally think it is a travesty that data Foo = Foo { a :: Int, b :: Char } | Bar { a :: Int } let x = Bar { a = 4 } y = x { b = 'x'}

Re: [Haskell] The next langauage definition version will be ``Haskell 1.6''

2005-11-02 Thread John Meacham
Long ago I determined I spent much more time deciding on the name of projects and what I should call releases than working on code so I decided to solve the issue once and for all and just started using a random password generator to generate release versions and project names. therefore, I

Re: [Haskell] specification of sum

2005-11-02 Thread John Meacham
On Wed, Nov 02, 2005 at 11:18:13AM -, Simon Marlow wrote: Also, we shouldn't be turning overloaded functions into class methods purely for the purposes of providing optimised versions; that's what the SPECIALISE pragma is for. I am a little torn on the issue, on one hand, if it is purely

[Haskell-cafe] Vector/matrix arithmetic

2005-11-02 Thread James McNeill
Im attempting to learn Haskell by writing some orbital mechanics code. Id like to use vector and matrix arithmetic to simplify it. The Haskell book Ive got, Simon Thompsons Haskell: The Craft of Functional Programming, has one approach, which is to alias a list of numbers to Vector, and a