- Glasgow-haskell-users

Straightforward conversion from Int <-> Word
by Jan-Willem Maessen 25 Feb '02

25 Feb '02

I've cast about a bit and haven't been able to find the appropriate functionality, so I'm asking here. I'd like to convert Int32 to and from Word32 in the good old-fashioned bitwise fashion (perserving modular arithmetic). I have the following code to show what I mean: intToNat i | i >= 0 = fromIntegral i | otherwise = fromIntegral (i - minBound) + negBound where negBound = fromInteger . negate . toInteger $ (minBound :: Int) One might think that "intToWord32" and "word32ToInt" in lang/Word would do what I want---but no! These are depracated, and I must use fromIntegral, which will only perform the conversion correctly for the portions of the numeric range which overlap. How do I do the straightforward conversion module 2^32? I'm sure it's buried in there somewhere... I can't even turn up an appropriate type signature, though. -Jan-Willem Maessen

1 0

RE: core language external representation
by Simon Peyton-Jones 25 Feb '02

25 Feb '02

Not yet. But Jeff Lewis is (I believe) planning to work actively on this. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 24 February 2002 16:55 | To: GHC Users Mailing List | Cc: apt(a)cs.pdx.edu | Subject: core language external representation | | | I know it's possible to get ghc to emit core at multiple | points, but is it possible to get it to read in core? For | instance, if a file is named blah.hco, perhaps parse it and | interpret it in the Core language format? If this isn't | currently possible, is there a plan to make it so? | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

RE: Does GHC simplify RULES?
by Simon Peyton-Jones 25 Feb '02

25 Feb '02

Josef, Ah, I see. I think you are trying to do something quite hard, akin to higher-order matching, which is the kind of thing Oege's MAG system does. I'm copying him so he can confirm or deny. In general, it is true that (\x. ...x...) E might match (f E), for some expression E, where (...E...) does not match. But since the two are beta-convertible, it's hard to ensure that the expression has the "right" form. Higher-order matching is simply matching modulo beta, which means that it wouldn't matter which form it's in. GHC does not do HO matching; it is tricky and expensive, and I think not suitable for a compiler. You are trying to help GHC with cunning crafting of your program, but as you observe it's all terribly fragile. That's not GHC's fault --- it's just that hand-driving HO matching is a fragile process. I have to say that I'm not very optimistic. I doubt that moving in the direction of switching off beta here and there would be a robust solution. Simon | -----Original Message----- | From: Josef Svenningsson [mailto:josefs@cs.chalmers.se] | Sent: 25 February 2002 14:30 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: RE: Does GHC simplify RULES? | | | On Mon, 25 Feb 2002, Simon Peyton-Jones wrote: | | > | > | Suppose I have the following RULES pragma: | > | | > | {-# RULES | > | "foo" forall a . foo a = (\x -> bar x) a | > | #-} | > | | > | Ok, it's stupid but I have examples where this is | motivated, trust | > | me. | > | | > | Now, it seems that GHC simplifies the rule because what I | get when | > | compiling it with -ddump-rules is the following rule: | > | | > | "foo" __forall {@ t_a2UD a :: t_a2UD} | > | Test.foo @ t_a2UD a | > | = Test.bar @ t_a2UD a ; | > | | > | It's \beta-reduced! Argh! Why is that? | > | > Because if it's left unsimplified, the first thing that will happen | > after the rule fires is that the beta reduction will be | done. So why | > not do it first? (The desugarer can leave quite a lot of | crud around, | > so a gentle simplification is indeed run.) | > | > You'll need to explain your motivation a bit more. Perhaps | give the | > rules you'd like along with a sample simplification sequence. | > | Alright. Some more motivation is probarbly justified here. | This message is a bit lengthy. If you're not very interested | in this I suggest you stop reading now. | | What I am really trying to do is trying to express the | foldr/build rule without build. Intuitively this should be | possible since build just sits a a tag on a function saying | that it has the right type. | | Expressing the foldr/build-build (read: foldr build minus | build) rule is | easy: | | {-# RULES | "foldr fuse" forall c n (g :: forall b . (a -> b -> b) -> b -> b). | foldr c n (g (:) []) = g c n | #-} | | Now, the problem is writing list producing functions so that | they get the right type. Let's look at an example, our | favourite function map. Suppose we have the following code snippet: | | foldr p z (map f xs) | | How do we write map so that the intermediate list is not | built? We can define map in the following way: | | map f xs = mapFB f xs (:) [] | | mapFB is a function where all the conses and nils are | abstracted out. Now, we can arrange so that map gets inlined | in the above example. So for the rule "foldr fuse" to apply | mapFB must have the right type. Note that mapFB takes four | arguments and g in the rule takes two. BUT, g takes a type | argument before these two arguments because it is | polymorphic. Therefore mapFB must also take a type argument | in that position in order for the rule to apply. With this in | mind we might try to give mapFB the following | type: | | mapaux :: (a -> b) -> [a] -> (forall c. (b -> c -> c) -> c -> c) | | But GHC completely ignores our explicit forall quantifier and | moves the quantification to the top level. Bummer! | | OK, so we want to force GHC to put a type lambda where we | want to. My idea was then to have a rule that generates a | piece of polymorphic code and insert some redundancy so that | GHC would not understand that it could remove the type | lambda. Here's what I tried: | | {-# RULES | "map" forall (f :: a -> b) xs . | map f xs = | ((\c n -> mapaux f xs c n) :: forall c . (a -> c -> c) -> | c -> c) (:) [] #-} | | The idea is to fool GHC to insert a lambda before my explicit | lambdas in the rhs of the rule. Then the "foldr fuse" rule | whould fire on the example above. Or will it? It depends on | how GHC does things and I'm not 100% sure. If GHC start | simplifying something which just came out of an application | of a rule then I guess this trick is really wasted. What I | hoped for was this: | | foldr p z (map f xs) ={ Rule "map" }=> | foldr p z ((\c n -> mapaux f xs c n) (:) []) ={ Rule "foldr | fuse" }=> (\c n -> mapaux f xs c n) p z ={ \beta reduction | }=> mapaux f xs p z | | In actual GHC the \beta reduction will probarbly happen | before the second rule application. But I suppose I would | have found that out if the rule was not simplified, now there | was no way to tell. | | Ok, so maybe you guys have already though about removing | build and decided against it. It might not be the most | important problem in the world. But intuitively build is | completely redundant and that really bugs me. That's why I've | been playing around with this. | | Cheers, | | /Josef | |

1 0

RE: Does GHC simplify RULES?
by Simon Peyton-Jones 25 Feb '02

25 Feb '02

| Suppose I have the following RULES pragma: | | {-# RULES | "foo" forall a . foo a = (\x -> bar x) a | #-} | | Ok, it's stupid but I have examples where this is motivated, trust me. | | Now, it seems that GHC simplifies the rule because what I get | when compiling it with -ddump-rules is the following rule: | | "foo" __forall {@ t_a2UD a :: t_a2UD} | Test.foo @ t_a2UD a | = Test.bar @ t_a2UD a ; | | It's \beta-reduced! Argh! Why is that? Because if it's left unsimplified, the first thing that will happen after the rule fires is that the beta reduction will be done. So why not do it first? (The desugarer can leave quite a lot of crud around, so a gentle simplification is indeed run.) You'll need to explain your motivation a bit more. Perhaps give the rules you'd like along with a sample simplification sequence. Simon

2 1

RE: IArray
by Simon Marlow 25 Feb '02

25 Feb '02

> After reading your email i went to the discussion of IArray > on the haskell > doc page > (http://www.haskell.org/ghc/docs/latest/set/sec-iarray.html) and > am somewhat disturbed by it. There is the introduction of > the following > class: > > > class HasBounds a where > > bounds :: Ix ix => a ix e -> (ix,ix) > > which is then used in: > > > class HasBounds a => IArray a e where > > array :: Ix ix => (ix,ix) -> [(ix,e)] -> a ix e > > (!) :: ... > > (//) :: ... It was factored this way because for certain array types we define a separate IArray instance for each element type (ie. for the unboxed UArray types), where for these types the definition of 'bounds' doesn't depend on the element type so it would be wasteful to include it in the IArray class. > > class Ix ix => HasBounds a ix | a -> ix where > > bounds :: a -> (ix,ix) Surely you mean class Ix ix => HasBounds a ix | a -> ix where bounds :: a e -> (ix,ix) ^^ don't forget the 'e'! > that way, we would efine things like: > > > instance Ix ix => HasBounds (Array.Array ix) ix where ... > > instance Ix ix => HasBounds (UArray ix) ix where ... Yes, this looks reasonable. Then of course Ix becomes a superclass of HasBounds and hence also of IArray, which will change quite a few types. I do remember trying various renderings of these two classes before I settled on these though: in particular I think making Ix a superclass caused problems (but I can't remember what exactly). Perhaps you could try it and let me know? Cheers, Simon

1 0

RE: strip effect
by Julian Seward (Intl Vendor) 25 Feb '02

25 Feb '02

Removes all low-level debugging information, which means that gdb et al can't navigate round your program. Apart from that, no effects (AFAIK). Is there a special reason why you ask? J | -----Original Message----- | From: Andre W B Furtado [mailto:awfurtado@uol.com.br] | Sent: Saturday, February 23, 2002 4:39 AM | To: glasgow-haskell-users(a)haskell.org | Subject: strip effect | | | What is the effect of using the "strip" command with the | files generated by | ghc (besides reducing the file size)? | | -- Andre | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

IArray
by David Feuer 25 Feb '02

25 Feb '02

What is IArray? This seems rather mysterious to me. David Feuer

2 2

core language external representation
by Hal Daume III 24 Feb '02

24 Feb '02

I know it's possible to get ghc to emit core at multiple points, but is it possible to get it to read in core? For instance, if a file is named blah.hco, perhaps parse it and interpret it in the Core language format? If this isn't currently possible, is there a plan to make it so? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Re: Congrats to Mandrake
by Marcin 'Qrczak' Kowalczyk 24 Feb '02

24 Feb '02

Tue, 19 Feb 2002 18:55:55 +0000, Jim Farrand <jim(a)farrand.net> pisze: >> > both hugs and ghc in their Linux distro *as standard*. This could >> > significantly help Haskell takeup amongst the unwashed masses. :-) >> Well, same applies for FreeBSD. > > And Debian. And PLD <http://www.pld.org.pl/>. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0

Building ghc-5.00.2 from .hc files
by Pawel Kolodziej 23 Feb '02

23 Feb '02

Hi. I have tried do build ghc-5.00.2 from .hc files. I run ditrib/hc-build, but it fails: ------------------------------------------------------------------------ ===fptools== Finished making `all' in cbits ... PWD = /tmp/ghc-5.00.2/hslibs/lang ------------------------------------------------------------------------ make[1]: *** No rule to make target `Addr.o', needed by `libHSlang.a'. Stop. make: *** [all] Error 1 make: Leaving directory `/tmp/ghc-5.00.2/hslibs' My box is ix86 running Linux (but I could not use binary version of ghc). Could you tell me what I should do to compile it from .hc files ? -- Pawel Kolodziej -- pawelk(a)pld.org.pl

1 0