- Haskell-Cafe - Haskell.org

Re: Why is there a space leak here?
by Fergus Henderson 05 Jun '01

05 Jun '01

David Bakin <davidbak(a)cablespeed.com> wrote: > I have been puzzling over this > for nearly a full day (getting this reduced version from my own code > which wasn't working). and Alastair Reid <reid(a)cs.utah.edu> replied: > Executive summary: David's program has an incredibly subtle space leak > in it (or I'm being incredibly dumb). I don't think you were being dumb. The space leak was easy enough to understand once explained, but I don't think it was obvious -- at any rate it was not obvious to me. I take this as another data point showing how lazy evaluation can cause space leaks that are difficult to debug. If experts like Alastair Reid have trouble understanding the operational behaviour of simplified examples like this one, how are ordinary programmers to cope with complicated programs? Is lazy functional programming too difficult for ordinary mortals? -- Fergus Henderson <fjh(a)cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

1 0

Re: [off-topic] LaTex for [[ ... ]]
by Fergus Henderson 01 Jun '01

01 Jun '01

Sorry for the off-topic post, but I figured someone here would know... can anyone please tell me how to do the double-square-bracket symbols that are often used in denotational semantics in LaTex? It's like "[[" but a single symbol without the space between the two brackets. (I checked the Latex companion, but it's not listed there AFAICT.) -- Fergus Henderson <fjh(a)cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

6 6

Re: [off-topic] LaTex for [[ ... ]]
by Keith Wansbrough 01 Jun '01

01 Jun '01

> Sorry for the off-topic post, but I figured someone here would know... > can anyone please tell me how to do the double-square-bracket symbols > that are often used in denotational semantics in LaTex? It's like > "[[" but a single symbol without the space between the two brackets. > (I checked the Latex companion, but it's not listed there AFAICT.) \newcommand{\lsem}{[\![} \newcommand{\rsem}{]\!]} is what I use; there are some real ones in \usepackage{stmaryrd} if you really want them. --KW 8-) -- Keith Wansbrough <kw217(a)cl.cam.ac.uk> http://www.cl.cam.ac.uk/users/kw217/ Cambridge University Computer Laboratory.

1 0

Re: Announcement: new HOpenGL Tutorial
by Sven Panne 30 May '01

30 May '01

[ redirected to haskell-cafe ] Ronald Legere wrote: > Looks great! I think the community will really > appreciate it. And I extremely appreciate it when other people write documentation for my stuff. :-) Thanks, great job! > I will have to 'give it a whirl' myself, if I can > ever get HOpenGL to compile on my solaris sparc. (I > keep having trouble with 'test' in the makefiles. I > must have a wierd version of test or something. I am no > OS guru :) (If anyone has ever seen this problem, let > me know ) Just a note: HOpenGL has been moved into GHC's fptools repository, and the tar balls on my web page are quite old. I'm not sure if they will work with more recent versions of GHC, so if you're totally stuck, join the bleeding edge and compile GHC from CVS, adding --enable-hopengl to configure's options. This builds an OpenGL package, too, but the resulting GHC doesn't know about it, so you will have to fiddle around with GHC's options a bit. Furthermore, the binding is not yet complete again, I guess about 80% has been ported. Not optimal, but I'm working on it... Alas, other Haskell systems are not yet supported, but given the recent advances in the FFI and library area, this will hopefully change in the near future. Cheers, Sven

1 0

Re: Functional programming in Python
by Marcin 'Qrczak' Kowalczyk 29 May '01

29 May '01

29 May 2001 22:44:38 +0200, Ketil Malde <ketil(a)ii.uib.no> pisze: > Wouldn't > x f g > in a Forth'ish machine mean > g(f,x) -- using "standard" math notation, for a change > rather than > g(f(x)) > ? It depends whether f changes the value at top of the stack or only puts something there. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Functional programming in Python
by Ketil Malde 29 May '01

29 May '01

Jerzy Karczmarczuk <karczma(a)info.unicaen.fr> writes: >> BTW, before I knew Haskell I exprimented with a syntax in which 'x f' >> is the application of 'f' to 'x', and 'x f g' means '(x f) g'. > Hmmm. An experimental syntax, you say... > Oh, say, you reinvented FORTH? Wouldn't x f g in a Forth'ish machine mean g(f,x) -- using "standard" math notation, for a change rather than g(f(x)) ? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Why is there a space leak here?
by Tom Pledger 29 May '01

29 May '01

David Bakin writes: : | I have been puzzling over this for nearly a full day (getting this | reduced version from my own code which wasn't working). In | general, how can I either a) analyze code looking for a space leak | or b) experiment (e.g., using Hugs) to find a space leak? Thanks! | -- Dave a) Look at how much of the list needs to exist at any one time. | -- This has a space leak, e.g., when reducing (length (foo1 1000000)) | foo1 m | = take m v | where | v = 1 : flatten (map triple v) | triple x = [x,x,x] When you consume the (3N)th cell of v, you can't yet garbage collect the Nth cell because it will be needed for generating the (3N+1)th, (3N+2)th and (3N+3)th. So, as you proceed along the list, about two thirds of it must be retained in memory. | -- This has no space leak, e.g., when reducing (length (foo2 1000000)) | foo2 m | = take m v | where | v = 1 : flatten (map single v) | single x = [x] By contrast, when you consume the (N+1)th cell of this v, you free up the Nth, so foo2 runs in constant space. | -- flatten a list-of-lists | flatten :: [[a]] -> [a] : Rather like concat? Regards, Tom

5 6

Re: Functional programming in Python
by Marcin 'Qrczak' Kowalczyk 29 May '01

29 May '01

Mon, 28 May 2001 10:23:58 +0100, Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> pisze: > It seems that right-associativity is so intuitive that even the > person proposing it doesn't get it right. :-) And even those who correct them :-) >> f x (foldr1 f xs) f x foldr1 f xs > > Wouldn't the rhs actually mean f x (foldr1 (f xs)) in current notation? No: f (x (foldr1 (f xs))) Basically Haskell's style uses curried functions, so it's essential to be able to apply a function to multiple parameters without a number of nested parentheses. BTW, before I knew Haskell I exprimented with a syntax in which 'x f' is the application of 'f' to 'x', and 'x f g' means '(x f) g'. Other arguments can also be on the right, but in this case with parentheses, e.g. 'x f (y)' is a function f applied to two arguments. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

Funny type.
by Jay Cox 29 May '01

29 May '01

One day I was playing around with types and I came across this type: >data S m a = Nil | Cons a (m (S m a)) The idea being one could use generic functions with whatever monad m (of course m doesn't need to be a monad but my original idea was to be able to make mutable lists with some sort of monad m.) Anyway in attempting to define a generic show instance for the above datatype I finally came upon: >instance (Show a, Show (m (S m a))) => Show (S m a) where > show Nil = "Nil" > show (Cons x y) = "Cons " ++ show x ++ " " ++ show y which boggles my mind. But hugs +98 and ghci -fallow-undecidable-instances both allow it to compile but when i try >show s on >s = Cons 3 [Cons 4 [], Cons 5 [Cons 2 [],Cons 3 []]] (btw yes we are "nesting" an arbitrary lists here! however structurally it really isnt much different from any tree datatype) we get ERROR - *** The type checker has reached the cutoff limit while trying to *** determine whether: *** Show (S [] Integer) *** can be deduced from: *** () *** This may indicate that the problem is undecidable. However, *** you may still try to increase the cutoff limit using the -c *** option and then try again. (The current setting is -c998) funny thing is apparently if you set -c to an odd number (on hugs) it gives *** The type checker has reached the cutoff limit while trying to *** determine whether: *** Show Integer *** can be deduced from: *** () why would it try to deduce Show integer? Anyway, is my instance declaration still a bit mucked up? Also, could there be a way to give a definition of show for S [] a? Heres my sample definition just in case anybody is curious. >myshow Nil = "Nil" >myshow (Cons x y) = "Cons "++ show x ++ > " [" ++ blowup y ++ "]" > where blowup (x:y:ls) = myshow x ++ "," ++ blowup (y:ls) > blowup (x:[]) = myshow x > blowup [] = "" Thanks, Jay Cox yet another non-academic person on this list.

6 5

Re: Type resolution problem
by Marcin 'Qrczak' Kowalczyk 29 May '01

29 May '01

Mon, 28 May 2001 17:53:38 -0700, Juan Carlos Arevalo Baeza <jcab(a)roningames.com> pisze: > Uncommenting the type expression above clears the error. > But, why can't the compiler deduce it by itself? Monomorphism restriction strikes again. See section 4.5.5 in the Haskell 98 Report. A pattern binding without an explicit type signature is considered monomorphic (must resolve to a simgle non-overloaded type) and points of usage or defaulting rules for numeric types determine the type (neither applies here). IMHO monomorphism restriction should be removed (the case for bindings of the form var = expr without type signature). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0