February 2002 - Glasgow-haskell-users

RE: Straightforward conversion from Int <-> Word
by Simon Marlow 26 Feb '02

26 Feb '02

If intToNat is a blunt instrument, then fromIntegral is the rapier :-) Remember Word is GHC-specific; the FFI doesn't define it. Simon > -----Original Message----- > From: Julian Seward (Intl Vendor) [mailto:v-julsew@microsoft.com] > Sent: 25 February 2002 16:57 > To: jmaessen(a)alum.mit.edu; glasgow-haskell-users(a)haskell.org > Subject: RE: Straightforward conversion from Int <-> Word > > > > I've found this annoying in the past, and have resorted to hitting > it on the head (GHC-specifically) with a blunt instrument: > > intToNat :: Int -> Word > intToNat (I# i#) = W# (unsafeCast# i#) > > This probably defeats the good intentions of the FFI designers, > but it kinda seems like it'll work on all reasonable architectures. > > J > > | -----Original Message----- > | From: Jan-Willem Maessen [mailto:jmaessen@alum.mit.edu] > | Sent: Monday, February 25, 2002 4:46 PM > | To: glasgow-haskell-users(a)haskell.org > | Subject: Straightforward conversion from Int <-> Word > | > | > | 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 > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users(a)haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > | > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

RE: Straightforward conversion from Int <-> Word
by Simon Marlow 26 Feb '02

26 Feb '02

> -----Original Message----- > From: Jan-Willem Maessen [mailto:jmaessen@alum.mit.edu] > Sent: 25 February 2002 16:46 > To: glasgow-haskell-users(a)haskell.org > Subject: Straightforward conversion from Int <-> Word > > > 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. But fromIntegral *does* do the right thing, doesn't it? > Numeric.showHex (fromIntegral (-1 :: Int32) :: Word32) "" "0xffffffff" it does it by a kind of roundabout route, but this is the defined behaviour (at least in GHC). And if you turn optimisation on, the fromIntegral should reduce to a simple cast. Cheers, Simon

1 0

Doubts in GHC
by Fernando Lins 25 Feb '02

25 Feb '02

Hello, IŽm new in this list and I think that itŽs a very good idea, because we can show our doubts. I have a doubt in GHC: How can we include a folder in the compiling process? Example: If one file called main.hs requires some others modules that are in one folder, how can compile it in GHC and include this folder? Thanks, Fernando _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

1 0

multiple processes and threads
by Dean Herington 25 Feb '02

25 Feb '02

I have an application that uses multiple processes and multiple threads together. What's the best way to detect child process terminations? The initial thread in the inital process serves as driver of the application. It creates child processes and threads to carry out portions of the computation. A natural way to have the driver detect termination of these child processes and threads would be to have the driver "listen" on a single MVar to which termination notices are "posted". Child threads would simply post their termination notices directly. For child processes, I'd like to have a single thread in the initial process execute (getAnyProcessStatus True False) repeatedly, posting a termination notice each time such a call returns. However, with the current implementation of Concurrent Haskell, when the thread pends on the getAnyProcessStatus call, the entire initial process pends. The best solution I've come up with so far, which is unsatisfying, is to have this thread poll periodically (that is, loop over (getAnyProcessStatus False False) and (threadDelay)). Is there a better way? Dean Herington

1 0

RE: Straightforward conversion from Int <-> Word
by Julian Seward (Intl Vendor) 25 Feb '02

25 Feb '02

I've found this annoying in the past, and have resorted to hitting it on the head (GHC-specifically) with a blunt instrument: intToNat :: Int -> Word intToNat (I# i#) = W# (unsafeCast# i#) This probably defeats the good intentions of the FFI designers, but it kinda seems like it'll work on all reasonable architectures. J | -----Original Message----- | From: Jan-Willem Maessen [mailto:jmaessen@alum.mit.edu] | Sent: Monday, February 25, 2002 4:46 PM | To: glasgow-haskell-users(a)haskell.org | Subject: Straightforward conversion from Int <-> Word | | | 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 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

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