jmaessen at alum.mit.edu
Thu Apr 13 16:03:04 EDT 2006
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
> was curious what I was in for.
Well, the differences really had to do with termination under an
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:
| 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.
> John Meacham - ⑆repetae.net⑆john⑈
> Haskell-prime mailing list
> Haskell-prime at haskell.org
More information about the Haskell-prime