Re: laziness again...
Jay Cox <[EMAIL PROTECTED]> writes: >>> where ins i = manipulates the first element of the list > if you mean that (ins i) :: [a] -> [a] manipulates the first element of > the list it takes then of course it is strict. because in It is strict in the head of the list, yes. I.e. it is defined as ...where ins i ((_,x):xs) = (i,x):xs Apologies for being unprecise. > PS: deepseq was mentioned earlier in either this list or the other main > Haskell list. I believe it was actually a DeepSeq module of some sort. After some heap profiling (which produces marvellous plots, but is very expensive in running time. My tests that normally (without profiling, or just -p) run in a couple of minutes took over an hour. Also, the graphs indicate quite a bit less than top, but I ascribe that to the RTS and garbage-collectables lying around), I'm starting to suspect I'm generating a lot of unevaluated thunks. Is there any good tutorial or other material dealing with, and improving (memory) performance by, strictness in Haskell? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: A View of Monads (Re: performance of monads)
Artie Gold writes: >One way to think of it is to look at a program as a partially ordered >set of calculations; some calculations need to occur before others, >other groups can occur in any order. In an imperative language you >specify a total ordering (which is overkill). This is a weak argument. First of all it is not the case that imperative coders always specify a total ordering: multitasking, threading and interrupts (and their projections into software as in Unix signals and asynchronous exceptions) are ways of specifying partial ordering when a total ordering would lose. The potential execution speedups of the partial ordering are probably quite real, emphasis of potential, and people having been trying to exploit it for decades now, yet the fast languages are still the imperative ones and the impure functional ones because they have the best fit to modern hardware designs. There is so much wealth invested in these modern cpus designs that it would cost 100s of billions of dollars to create competitors best fitted to pure functional languages. Hint: you need to write a new OS design to go with your new hardware design, then attract users and developers to the OS. And nobody's going to invest that dough there because no single organization stands to gain anywhere near what it would cost. Note that modern cpu designs use "out-of-order" execution strategies; so on micro-second timescales they ignore the total ordering when doing so suits them and when it preserves semantics. There's a case for FP, but parallel execution opportunities is not it. The case for FP is superior abstracting ability. See John Hughes, Why Functional Programming Matters. I guess you could view not having to specify instruction ordering when you do not need to as a sort of abstracting, but I have yet to see code that profits from that kind of abstraction. If that's your argument, show me code examples; that's what Hughes did in his paper. No grudge against you, Artie Gold. This is pent-up frustration at many posters who've made the same argument >"May you keep turning the pages. And may the book never end." You, too. -- Richard Uhtenwoldt ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: laziness again...
On Mon, 18 Feb 2002, Jay Cox wrote: > On 18 Feb 2002, Ketil Z. Malde wrote: > > > > > Hi, > > > > I'm a bit puzzled by this observatio that I made. I have a function > > that, pseudocoded, lookes somewhat like > > > > f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) > > where ins i = manipulates the first element of the list > > > > Now, without the ins'es, the function appears to be lazy, i.e I can > > "take" a part of it without evalutating the rest. With the ins'es, > > the whole thing seems to be calculated as soon as I touch it. > > > > Is this obvious? Or is my observation wrong? > > > > -kzm > > > um, looks like ins i returns a function of one argument which results > in a list. (or ins is a function of two arguments which results in a list > and ins i is just using currying; however you want to look at it) > > My question is if that function (ins i) is strict. > > Jay . I should have read your letter more closely. > > where ins i = manipulates the first element of the list if you mean that (ins i) :: [a] -> [a] manipulates the first element of the list it takes then of course it is strict. because in ins i = \x -> case x of (a:as) -> foo a : as [] -> [] where foo a = ... ((ins i) list) must pattern match on list. therefore (ins i) _|_ = _|_ QED. I guess the kind of strictness I was thinking about is something along the lines of what you might get if you applied deepseq to the list (if such a type of strictness has been defined by anybody!) I got a bit confused. (example definition for sake of argument) (a:xs) ++ list = a:(xs ++ list) [] ++ list = list If (ins i) had such deep strictness then when the first element of (f i as bs cs) was forced, haskell would generate all of the list created by (ins i (f (i+1) as) since (++) is strict in the first argument. however, (:) is strict in neither argument, so (++) is lazily applied. Anyway... You might follow Bernard James POPE <[EMAIL PROTECTED]> recent posting (Subject: re: order of evaluation) about using "undefined" in the list to see how things are being evaluated, like in list = 3:4:5:undefined or list = 3:4:5:error "foo" (I got that idea from one of Simon Marlow's papers) Jay Cox PS: deepseq was mentioned earlier in either this list or the other main Haskell list. I believe it was actually a DeepSeq module of some sort. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: laziness again...
On 18 Feb 2002, Ketil Z. Malde wrote: > > Hi, > > I'm a bit puzzled by this observatio that I made. I have a function > that, pseudocoded, lookes somewhat like > > f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) > where ins i = manipulates the first element of the list > > Now, without the ins'es, the function appears to be lazy, i.e I can > "take" a part of it without evalutating the rest. With the ins'es, > the whole thing seems to be calculated as soon as I touch it. > > Is this obvious? Or is my observation wrong? > > -kzm um, looks like ins i returns a function of one argument which results in a list. (or ins is a function of two arguments which results in a list and ins i is just using currying; however you want to look at it) My question is if that function (ins i) is strict. Jay ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Trouble with DtdToHaskell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've got a debian install (2.2.18kernel, 2.95.4 gnu c compiler) with ghc
installed using hmake. I also found DtdToHaskell was installed on my
computer. I run it on any Dtd and get the following:
spg@Further:~/clean$ DtdToHaskell clean.dtd
module DTD_clean where
import Xml2Haskell
{-Type decls-}
{-Instance decls-}
{-Done-}
This also happens if I compile DtdToHaskell myself from the source. Any ideas
what's misconfigured?
- --
You're in a maze of twisty little statements, all alike.
Public Key available from http://www.garbett.org/public-key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8cQ/ZDtpPjAQxZ6ARAopFAJ4pePWkXo3TCtadkBR67zHHWoGPRwCfT8qL
86iZ8hdUPZHhbSA3DUVhB84=
=k7Ax
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
laziness again...
Hi, I'm a bit puzzled by this observatio that I made. I have a function that, pseudocoded, lookes somewhat like f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) where ins i = manipulates the first element of the list Now, without the ins'es, the function appears to be lazy, i.e I can "take" a part of it without evalutating the rest. With the ins'es, the whole thing seems to be calculated as soon as I touch it. Is this obvious? Or is my observation wrong? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
