- Glasgow-haskell-users

Socket Options
by Peter Simons 28 Jun '04

28 Jun '04

Hi, the Network module provides the data type SocketOption. I am particularly interested in setting the RecvTimeOut and SendTimeOut values, but I wonder how to set them. The function setSocketOption :: Socket -> SocketOption -> Int -> IO () allows me only 'Int' parameters, but the kernel expects a struct timeval here -- or more accurately, a pointer to one. Do I really have to engage in FFI pointer wizardry here, or is there a simpler way to set these values? Am I even supposed to set them, or is there a better way to specify general I/O timeouts than on the socket level? Peter

2 2

SPECIALIZE pragma
by Ross Paterson 28 Jun '04

28 Jun '04

Digging around in the source code comments, I found a restriction that is biting me: > We *insist* that all overloaded type variables are specialised to ground > types, (and hence there can be no context inside a SPECIALIZE pragma). The latter is fine, but the former seems too restrictive. For example, a function with constraints (Storable a, Eq a) can't be specialized to Ptr b, even though b would be unconstrained. Any hope of relaxing this?

1 1

RE: Strictness confusion
by Simon Peyton-Jones 25 Jun '04

25 Jun '04

Indeed. GHC's existing strictness analyser answers precisely this question too -- that's not the point. The question is what it does with the information. At the moment the info flows upwards to x's binding site. What's wanted here is to make it flow downwards to x's uses. S | -----Original Message----- | From: Alastair Reid [mailto:alastair@reid-hoffmann.net] | Sent: 25 June 2004 09:37 | To: glasgow-haskell-users(a)haskell.org | Cc: Simon Peyton-Jones; Ian Lynagh | Subject: Re: Strictness confusion | | On Friday 25 June 2004 09:17, Simon Peyton-Jones wrote: | > b) Adding a new top-down sweep to the strictness analyser. | > (e.g. "what demand is placed on x by evaluating (f (g x))?"). | | IIRC, the Yale Haskell compiler did this kind of thing. I joined the Yale | team late in the development so I don't know how effective it was or what the | interesting issues were but there's plenty of papers/ research reports about | Yale's strictness analysis and optimization. | | -- | Alastair Reid

1 0

RE: Strictness confusion
by Simon Peyton-Jones 25 Jun '04

25 Jun '04

Interesting: 1. When GHC decides that 'foo' is strict, it does not *require* that every caller must evaluate the argument before the call. So GHC does not assume that foo always gets an evaluated argument. Indeed, if GHC sees the call (foo v), where foo is strict, it does not evaluate v before the call. Nor in the case of (map foo xs). 2. When GHC sees case x of pat -> .....(case x of DEFAULT -> e)... ... it removes the (case x of DEFAULT ->), because it can "see" that x is already evaluated. [A 'seq' turns into one of those (case x of DEFAULT) things.] This transformation is done by the simplifier, which keeps an environment mapping variables to information about their degree of evaluation. However, if the outer case was case (f x) of pat -> ... then GHC does not record anything about x, even if f is strict. I guess it could, by making use of f's strictness information. But then what about case (f (g x)) of ... where both f and g are strict? Etc. One could imagine either a) Beefing up the existing simplifier optimisation in a relatively ad hoc way. Advantage: applies even if the (case x of DEFAULT) thing shows up much later Disadvantage: probably a bit ad hoc, and the simplifier is already v complicated b) Adding a new top-down sweep to the strictness analyser. Actually it could be done separately from strictness analysis, but would use much of the same code (e.g. "what demand is placed on x by evaluating (f (g x))?"). Advantage: doesn't complicated the already-complex simplifier The new pass ("case optimisation", perhaps) could remove some stuff from the too-complex simplifier Disadvantage: a new pass I'm not terribly inclined to do this myself, unless someone convinces me that there are big gains to be had, but I'd be happy to support someone who already knows GHC a bit (Ian?) if you want to have a go. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ian Lynagh | Sent: 25 June 2004 02:39 | To: glasgow-haskell-users(a)haskell.org | Subject: Strictness confusion | | | Hi all, | | If I have the following module: | | ----------8<--------------------8<---------- | module Q (foo) where | | foo :: String -> [String] -> Bool | #ifdef FIRST | foo x _ | x `seq` x == "." = True | #else | foo x _ | x == "." = True | #endif | foo x xs = x `seq` any (x ==) xs | ----------8<--------------------8<---------- | | then I would expect the code to be identical regardless of whether FIRST | is defined or not. However, the following shows that (without the first | seq) GHC forces the evaluation of x due to the seq in the last line. | But, as I understand it, it should know that x has already been | evaluated (to WHNF). This also seems to affect what gets inlined in | larger examples. | | Am I confused? | | $ rm -f *.o | $ /usr/bin/ghc -ddump-simpl -cpp -O -c Q.hs -DFIRST > 1 | $ rm -f *.o | $ /usr/bin/ghc -ddump-simpl -cpp -O -c Q.hs > 2 | $ diff -u1000 1 2 | --- 1 Fri Jun 25 02:11:46 2004 | +++ 2 Fri Jun 25 02:12:02 2004 | @@ -1,32 +1,34 @@ | | ==================== Tidy Core ==================== | Q.a :: GHC.Base.Char | [GlobalId] | NoCafRefs Str: DmdType m | Q.a = GHC.Base.C# '.' | | Q.lvl :: [GHC.Base.Char] | [GlobalId] | NoCafRefs Str: DmdType | Q.lvl = GHC.Base.: | @ GHC.Base.Char Q.a (GHC.Base.[] @ GHC.Base.Char) | | Q.foo :: GHC.Base.String -> [GHC.Base.String] -> GHC.Base.Bool | [GlobalId] | Arity 2 NoCafRefs Str: DmdType SL | Q.foo = \ x :: GHC.Base.String ds :: [GHC.Base.String] -> | case GHC.Base.eqString x Q.lvl of wild { | GHC.Base.True -> GHC.Base.True; | GHC.Base.False -> | + case x of tpl { __DEFAULT -> | GHC.List.any | @ GHC.Base.String | - (\ ds1 :: GHC.Base.String -> GHC.Base.eqString x ds1) | + (\ ds1 :: GHC.Base.String -> GHC.Base.eqString tpl ds1) | ds | + } | } | | | | | ==================== Tidy Core Rules ==================== | | | $ | | | Thanks | Ian | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Strictness confusion
by Ian Lynagh 25 Jun '04

25 Jun '04

Hi all, If I have the following module: ----------8<--------------------8<---------- module Q (foo) where foo :: String -> [String] -> Bool #ifdef FIRST foo x _ | x `seq` x == "." = True #else foo x _ | x == "." = True #endif foo x xs = x `seq` any (x ==) xs ----------8<--------------------8<---------- then I would expect the code to be identical regardless of whether FIRST is defined or not. However, the following shows that (without the first seq) GHC forces the evaluation of x due to the seq in the last line. But, as I understand it, it should know that x has already been evaluated (to WHNF). This also seems to affect what gets inlined in larger examples. Am I confused? $ rm -f *.o $ /usr/bin/ghc -ddump-simpl -cpp -O -c Q.hs -DFIRST > 1 $ rm -f *.o $ /usr/bin/ghc -ddump-simpl -cpp -O -c Q.hs > 2 $ diff -u1000 1 2 --- 1 Fri Jun 25 02:11:46 2004 +++ 2 Fri Jun 25 02:12:02 2004 @@ -1,32 +1,34 @@ ==================== Tidy Core ==================== Q.a :: GHC.Base.Char [GlobalId] NoCafRefs Str: DmdType m Q.a = GHC.Base.C# '.' Q.lvl :: [GHC.Base.Char] [GlobalId] NoCafRefs Str: DmdType Q.lvl = GHC.Base.: @ GHC.Base.Char Q.a (GHC.Base.[] @ GHC.Base.Char) Q.foo :: GHC.Base.String -> [GHC.Base.String] -> GHC.Base.Bool [GlobalId] Arity 2 NoCafRefs Str: DmdType SL Q.foo = \ x :: GHC.Base.String ds :: [GHC.Base.String] -> case GHC.Base.eqString x Q.lvl of wild { GHC.Base.True -> GHC.Base.True; GHC.Base.False -> + case x of tpl { __DEFAULT -> GHC.List.any @ GHC.Base.String - (\ ds1 :: GHC.Base.String -> GHC.Base.eqString x ds1) + (\ ds1 :: GHC.Base.String -> GHC.Base.eqString tpl ds1) ds + } } ==================== Tidy Core Rules ==================== $ Thanks Ian

1 0

Instances for Storable
by Nivia Q. 24 Jun '04

24 Jun '04

Hi GHC users, I've been trying to create a instance for Maybe type in the Storable class. I need to override the peek and poke methods, but I'm having some difficulties. I was intended to do something like this: instance Storable t =>Storable (Maybe t) where peek ptr = maybePeek peek ptr poke ptr valMaybe = do ptr<-maybeNew (new) valMaybe return() Obviously, there is a type error on the definition of peek, because the type of prt is (Ptr a), not (Ptr (Maybe a)) . I don't know how to fix it and, at the same time, keep using instanciation. I would be grateful for suggestions, Regards, _________________________________________________ Nivia Cruz Quental Graduação em Eng. Computação - UPE Técnica em Telecomunicações - CEFET-PE - Brasil --------------------------------- Crie seu Yahoo! Mail, agora com 100MB de espaço, anti-spam e antivírus grátis!

1 0

ObjectIO
by Gracjan Polak 22 Jun '04

22 Jun '04

Hi, In the following code only processInit and processClose get ever called, other callbacks are *never* invoked. Is this known problem? Do I miss something obvious? How do I get the handle of main window? Here is the code: module Main where import Graphics.UI.ObjectIO processAttributes = [ ProcessActivate processActivate , ProcessDeactivate processDeactivate , ProcessClose processClose , ProcessOpenFiles processOpenFiles -- , ProcessWindowPos ItemPos -- , ProcessWindowSize Size , ProcessWindowResize processWindowResize --, ProcessToolbar [ToolbarItem ps] -- , ProcessNoWindowMenu ] processInit ps = do liftIO $ putStrLn "processInit" return ps processActivate ps = do liftIO $ putStrLn "processActivate" return ps processDeactivate ps = do liftIO $ putStrLn "processDeactivate" return ps processClose ps = do liftIO $ putStrLn "processClose" closeProcess ps processOpenFiles files ps = do liftIO $ putStrLn ("processOpenFiles " ++ show files) return ps processWindowResize oldsize newsize ps = do liftIO $ putStrLn ("processWindowResize" ++ show newsize) return ps main = do startIO SDI () processInit processAttributes -- Pozdrawiam, Regards, Gracjan

1 1

Lazy version of peekArray
by Gracjan Polak 22 Jun '04

22 Jun '04

Hi, I'm trying to make use of memory mapped files with Haskell. It is kind of fun, I managed to mmap a file (actualy CreateFileMapping, because I'm on a Windows box), managed to setup finalizers (those kind of work now, see my posts about finalizers and FFI). Now I got to content... and here is the problem. Data I want to read is large, mostly binary with parts that must be parsed. But peekArray is not lazy (is IO action), produces large lists in strict mode. So I had to write my own thing. Provided that underlying data does not change following unsafeLazyPeekArray and friends should be good. Does anybody see any problems in following code? Maybe there is something obvious I do not see... Those functions were designed to be list less, when used in producer consumer fashion list will not be generated (I hope). Is current state GHC compiler smart enough to optimize this efficiently? How can I help it with this task (maybe a pragma here and there?) Anyway, the code. Maybe someone find it interesting: unsafeLazyPeekArray size ptr = unsafeLazyPeekArrayOffset 0 size ptr unsafeLazyPeekArrayOffset :: Storable a => Int -> Int -> ForeignPtr a -> [a] unsafeLazyPeekArrayOffset offset size ptr | size <= 0 = [] | otherwise = unsafePerformIO $ helper offset where helper index | index >= size = return [] | otherwise = unsafeInterleaveIO $ do x <- withForeignPtr ptr (\xptr -> peekElemOff xptr index) xs <- helper (index+1) return (x:xs) unsafeLazyPeekArrayOffset0 :: (Storable a, Eq a) => Int -> a -> ForeignPtr a -> [a] unsafeLazyPeekArrayOffset0 offset marker ptr = unsafePerformIO $ helper offset where helper index = unsafeInterleaveIO $ do x <- withForeignPtr ptr (\xptr -> peekElemOff xptr index) if x==marker then return [] else do xs <- helper (index+1) return (x:xs) unsafeLazyPeekArray0 :: (Storable a, Eq a) => a -> ForeignPtr a -> [a] unsafeLazyPeekArray0 marker ptr = unsafeLazyPeekArrayOffset0 0 marker ptr -- Pozdrawiam, Regards, Gracjan

1 0

RE: Understanding strictness of ghc output
by Simon Marlow 22 Jun '04

22 Jun '04

On 22 June 2004 15:59, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> Nope. You can't return something without evaluating it to head >> normal form in Haskell. Every value that is "returned" is a value, >> never a thunk. If you want to return something unevaluated, you >> have to wrap it in a constructor. > > Actually, there are two possible strategies for who evaluates a thunk > to head normal form. The caller or the callee. GHC says that the > callee always evaluates to HNF before returning the value. But the > language does not force this implementation choice. It is equally > possible for an implementation of the function to return a thunk and > for the caller to evaluate it if necessary. Both strategies give the > same result semantically, since if the value in question is demanded, > it gets evaluated. If a function is called, then the result has been demanded. There are no situations in which a function has been called but the caller will accept a thunk as the result without further evaluating it. So what is the advantage of returning a possibly-unevaluated result? The caller will definitely have to evaluate it, so every eval will need to loop until the value is in HNF. And what about updates? Cheers, Simon

2 1

RE: Understanding strictness of ghc output
by Simon Peyton-Jones 22 Jun '04

22 Jun '04

it means Lazy, but it's misleading for unboxed types | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Adrian Hey | Sent: 22 June 2004 17:09 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: Understanding strictness of ghc output | | On Tuesday 22 Jun 2004 2:28 pm, Simon Peyton-Jones wrote: | > The DmdType for the Int# is indeed "L" but that's irrelevant because | > Int# values are always evaluated. The demand info is always L for an | > unboxed type. | | Thanks, I had noticed it did appear to have decided h was unboxed | (assuming my interpretation of core was correct), so it seemed rather | strange that addHeight could be lazy (non-strict) in that argument. | | So does L mean "Lazy", or something else? | | Thanks | -- | Adrian Hey | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0