May 2002 - Glasgow-haskell-users

getting a grip on memory usage
by Hal Daume III 22 May '02

22 May '02

so i have a function that is eating *tons* of memory. my application is clustering and i put everything in UArrays or Arrays. for clustering 5 data points with 4 features (a tiny tiny set) the program gobbles 350mbs! most of the usage is coming from this distance function: dist dat Nothing pq@(p,q) = (uncurry loop) (bounds xp) 0 (\a i -> a + (sqr (xp!i - xq!i))) where Vector xp = dat !!! p Vector xq = dat !!! q dist dat (Just (Vector w)) pq@(p,q) = (uncurry loop) (bounds xp) 0 (\a i -> a + ((sqr (w!i)) * (sqr (xp!i - xq!i)))) where Vector xp = dat !!! p Vector xq = dat !!! q Where the relevant definitions are: type Vector = Vector (UArray Int Double) (!!!) = Array.(!) and loop is: loop :: (Num i, Ord i, Ix i) => i -> i -> a -> (a -> i -> a) -> a loop low high a f = loop' a low where loop' a pos | pos > high = a | otherwise = loop' (f a pos) (pos+1) i cannot figure out why such a function would be eating so much memory. i even tried changing the function provided to loop with "a `seq` ..." to make sure we're not creating a huge thunk, but that didn't help at all. but, according to my profiling: dist Main 380000 27.7 23.6 64.9 61.0 sqr Main 2280000 1.6 7.9 1.6 7.9 !!! Main 760000 4.7 0.0 4.7 0.0 loop Loops 380000 30.8 29.5 30.8 29.5 i realize it's being entered a lot of times, and i can understand that it would use a bunch of time resources, but i don't understand why it's using so much space. any help would be appreciated... - 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

2 1

LGPL and static linking of libgmp
by Wolfgang Thaller 22 May '02

22 May '02

I just re-read the GNU Lesser General Public License today - and I discovered that it places some utterly strange (IMHO) restrictions on executables statically linked with LGPLed libraries. Unfortunately, GHC for Windows produces such executables by linking in libgmp statically. Dynamically linking with libgmp would cause no restrictions, but if it is statically linked, the LGPL says that everyone distributing a program compiled with GHC has to 'Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)' I think it would be best to have future distributions of GHC for Windows include libgmp as a DLL. That's what I'll be doing for my future releases of GHC for MacOS X. Cheers, Wolfgang Thaller

1 0

RE: -fallow-overlapping-instances Request
by Simon Peyton-Jones 21 May '02

21 May '02

I don't understand all the implications of this. For example, what if we have an instance that doesn't match C () () now, but may do 'later' when a type variable has been instantiated. Overlapping instances are a terrific swamp and while they are interesting I don't think I'm going to spend a lot of time on them in the near future, I'm afraid. But perhaps someone else can.. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 17 May 2002 10:02 | To: GHC List | Subject: -fallow-overlapping-instances Request | | | Currently -fallow-overlapping-instances only allows | overlapping instances | if one is a strict subset of the other. This is good | (determinate), but | sometimes you really need two instances that partially | overlap. It would | be nice if this could be disambiguated simply with another instance | declaration. For instance: | | class C a b; | instance C a (); | instance C () a; | instance C () (); | | As you can see, the first two instances partially overlap, | but the third | one disambiguates. I think it would be nice if GHC | -fallow-overlapping-instances allowed this. | | This would take some of the pain out of overlapping instance | resolution... | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

Re: -fallow-overlapping-instances Request
by Ashley Yakeley 18 May '02

18 May '02

At 2002-05-17 03:54, Johannes Waldmann wrote: >From a type-theoretic viewpoint, >instance declarations are relations between (sets of) trees >(= elements of the respective data types). >So one needs representations of such relations >with effective decidability of overlapping-ness, most-sepcific-ness and such. Yeah but unfortunately GHC doesn't look at the contexts of instance declarations. It has a straightforward but rather conservative concept of "overlapping" and "most specific". I'd like to see that fixed too, but that's a separate issue. -- Ashley Yakeley, Seattle WA

1 0

RE: efficiency of UArray
by Simon Peyton-Jones 17 May '02

17 May '02

GHC doesn't remove intermediate lists down both branches of a zip, so yes, you'll get intermediate lists. Why not use array indexing, as per your second version (only in Haskell)? Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 16 May 2002 00:55 | To: GHC Users Mailing List | Subject: efficiency of UArray | | | can we expect a function like: | | sum [x*y | (x,y) <- zip (elems v) (elems u)] | | to be as efficient as, say: | | sum = 0 | for i=1, n | sum = sum + v[i] * u[i] | | ? | | Basically, will any intermediate lists be created here? | | -- | 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 |

3 2

-fallow-overlapping-instances Request
by Ashley Yakeley 17 May '02

17 May '02

Currently -fallow-overlapping-instances only allows overlapping instances if one is a strict subset of the other. This is good (determinate), but sometimes you really need two instances that partially overlap. It would be nice if this could be disambiguated simply with another instance declaration. For instance: class C a b; instance C a (); instance C () a; instance C () (); As you can see, the first two instances partially overlap, but the third one disambiguates. I think it would be nice if GHC -fallow-overlapping-instances allowed this. This would take some of the pain out of overlapping instance resolution... -- Ashley Yakeley, Seattle WA

2 1

RE: infix type constructors
by Okasaki, C. DR EECS 16 May '02

16 May '02

Simon wrote: > I'm slowly getting around to this. Design questions: > > (A) I think it would be a good compromise to declare that operators > like "+" are type *constructors* not type *variables*. So > S+T > would be a type. That's slightly inconsistent with value variables, > but it's jolly useful. So only alphabetic things would be type > variables. > It's very clunky having to write > S :+: T As a design principle, I would recommend keeping type constructors and value constructors as similar as possible. So I would require infix type constructors to begin with a :, just like value constructors. Yes, it's clunky, but no more clunky than for value constructors. > (B) One wants to declare fixities for type constructors, and that > gets them mixed up with their value counterparts. My suggestion: > disamiguate with a compulsory 'type' keyword > infix 6 type + > infixl 9 type * > > Or should it be 'data'? Or should it depend how + and * are declared? My preference here would be for an infix declaration for a given name to apply to both type and value constructors. So, if you have a type constructor :- and a value constructor :-, they will have exactly the same precedence and associativity. I think it would be far too confusing for a type a :-: b :+: c to parse differently than an expression x :-: y :+: z > (C) The other place they can get mixed up is in import and export > lists. I can think of several solutions > > (i) module Foo( + ) where ... > means export the type constructor (+); currently illegal in H98 > module Foo( (+) ) where ... > means export the variable (+). > > This seems a bit of a hack. > > (ii) Use the 'type' keyword, rather like 'module': > module Foo( type + ) where > data a+b = A a | B b > or > module Foo( type +(A,B) ) where > data a+b = A a | B b > > [I think 'type' is better than 'data' because we want to hide the > distinction in an export list.... or do you think we should use the > same keyword as the one in the defn?] > > Similarly on import lists. If you keep the : prefix for infix type constructors, then this issue doesn't arise, just as it doesn't for alphabetic type and value constructors. > (D) I suppose one might want infix notation for type variables too: > > data T a = T (Int `a` Int) > > but maybe that's going too far? I don't have a strong feeling either way about this one. -- Chris

1 0

?? Redirecting standar error output ...
by heron_carvalho＠bol.com.br 16 May '02

16 May '02

Hello, How can I redirect standard error output to a file in GHC 5.02 ?? Something like -odump flag in GHC 4.08 ... Best Regards, Heron de Carvalho __________________________________________________________________________ Quer ter seu próprio endereço na Internet? Garanta já o seu e ainda ganhe cinco e-mails personalizados. DomíniosBOL - http://dominios.bol.com.br

1 0

RE: infix type constructors
by Simon Peyton-Jones 16 May '02

16 May '02

Chris I'm slowly getting around to this. Design questions: (A) I think it would be a good compromise to declare that operators like "+" are type *constructors* not type *variables*. So S+T would be a type. That's slightly inconsistent with value variables, but it's jolly useful. So only alphabetic things would be type variables. It's very clunky having to write S :+: T (B) One wants to declare fixities for type constructors, and that gets them mixed up with their value counterparts. My suggestion: disamiguate with a compulsory 'type' keyword infix 6 type + infixl 9 type * Or should it be 'data'? Or should it depend how + and * are declared? (C) The other place they can get mixed up is in import and export lists. I can think of several solutions (i) module Foo( + ) where ... means export the type constructor (+); currently illegal in H98 module Foo( (+) ) where ... means export the variable (+). This seems a bit of a hack. (ii) Use the 'type' keyword, rather like 'module': module Foo( type + ) where data a+b = A a | B b or module Foo( type +(A,B) ) where data a+b = A a | B b [I think 'type' is better than 'data' because we want to hide the distinction in an export list.... or do you think we should use the same keyword as the one in the defn?] Similarly on import lists. (D) I suppose one might want infix notation for type variables too: data T a = T (Int `a` Int) but maybe that's going too far? Simon | -----Original Message----- | From: Okasaki, C. DR EECS [mailto:Christopher.Okasaki@usma.edu] | Sent: 03 May 2002 14:09 | To: 'glasgow-haskell-users(a)haskell.org' | Subject: infix type constructors | | | I'm not sure how long this has been implemented in GHC, | but I just noticed that infix type constructors are allowed, | as in | | data a :- b = ... | | The syntactic asymmetry between type constructors and | data contructors has bothered me for a while, so this | is a welcome change! However, this syntax seems to | be supported for "data" and "newtype" declarations, | but not for "type" declarations. For example, | | type a :- b = ... | | does not seem to be allowed. Is there a reason for this? | Or was it just an oversight? | | -- Chris | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

RE: syntax of RULES pragmas?
by Simon Peyton-Jones 16 May '02

16 May '02

You need -fglasgow-exts. (Should ignore a pragma without -fglasgow-exts, and does so now, but 5.03 gave the bad message you found.) The manual is wrong; spaces between the variables is right. Simon | -----Original Message----- | From: Janis Voigtlaender [mailto:voigt@orchid.inf.tu-dresden.de] | Sent: 16 May 2002 14:49 | To: glasgow-haskell-users(a)haskell.org | Subject: syntax of RULES pragmas? | | | Hi, | | I was trying to play with GHC 5.02's RULES pragmas, but | failed due to syntax problems. | | When trying: | | {-# RULES "map/map" forall f g xs. map f (map g xs) = map | (f.g) xs #-} | | main = print (map id (map id "Hello")) | | I get: | | ghc5 test.hs -O | test.hs:1: Variable not in scope: `forall' | | test.hs:1: Variable not in scope: `f' | | test.hs:1: Variable not in scope: `g' | | test.hs:1: Variable not in scope: `xs' | | test.hs:1: Variable not in scope: `f' | | test.hs:1: Variable not in scope: `g' | | test.hs:1: Variable not in scope: `xs' | | test.hs:1: Variable not in scope: `f' | | test.hs:1: Variable not in scope: `g' | | test.hs:1: Variable not in scope: `xs' | Exit 1 | | | With: | | {-# RULES "map/map" forall f g xs. | map f (map g xs) = map (f.g) xs #-} | | main = print (map id (map id "Hello")) | | I get: | | test.hs:2: parse error (possibly incorrect indentation) | Exit 1 | | | In the user's doc on http://www.haskell.org/ghc/ I also saw | the syntax: | | {-# RULES "map/map" forall f,g,xs. map f (map g xs) = map | (f.g) xs #-} | | main = print (map id (map id "Hello")) | | which fails with: | | test.hs:1: parse error on input `,' | Exit 1 | | | So how exactly do I have to specify a rewrite rule? Any hints | appreciated. | | Thanks, Janis. | | | -- | Janis Voigtlaender | http://wwwtcs.inf.tu-dresden.de/~voigt/ | mailto:voigt@tcs.inf.tu-dresden.de | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0