On Apr 12, 2006, at 4:25 PM, John Meacham wrote:
On Wed, Apr 12, 2006 at 09:21:10AM -0400, Jan-Willem Maessen wrote:
Though, to be fair, an awful lot of Prelude code didn't work in pH unless it was re-written to vary slightly from the specification. So the assumption of laziness was more deeply embedded than the spec was willing to acknowledge.
out of curiosity what sort of things had to be rewritten? I have been toying with the idea of relaxing sharing to help some optimizations and was curious what I was in for.
Well, the differences really had to do with termination under an eager strategy. But beyond obvious problems such as defining things in terms of take + iterate (numericEnumFrom[Then]To is an obvious example), we ran into terrible performance problems with Read instances. Programs would spend minutes running read, then a few fractions of a second computing. We ended up doing a lot of tweaking, none of which was ever quite correct. Ditching ReadS in terms of ReadP would do an enormous amount of good here, I think---it would at least put all the re-coding in one centralized place, which is what we ended up having to do anyhow. Finally, there are a bunch of Haskell idioms which don't work in pH. The most obvious examples are numbering a list: zip [0..] xs and where-binding a value which is unused in one clause: f x | p x = ... r ... | q x = ... r ... | otherwise = ... no r ... where r = something very expensive I suppose you could view this as a "sharing problem": the expression r is shared down two of the branches and not down the other. But I don't think that's what you meant. A lot of these can be solved by a certain amount of code motion---but note that this code motion changes the termination properties of the program as it was written. In pH that was naughty. -Jan
John
-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime