sounds like folks criticize haskell (and probably rightly so) for not having a good definition, so implementations can ethically vary widely. so which fp actually does have well nailed-down semantics? plus a useful-in-the-real-world implementation (or two or three)?
raould <rao...@gmail.com> writes: > sounds like folks criticize haskell (and probably rightly so) for not > having a good definition, so implementations can ethically vary > widely.
So far I've found that more of a theoretical than a practical problem. (-:
> so which fp actually does have well nailed-down semantics?
I'd have guessed that Standard ML probably does? The folks over on comp.lang.functional might know better. From a practical view, I wonder if Erlang would have to as well.
> plus a useful-in-the-real-world implementation (or two or three)?
raould <rao...@gmail.com> writes: > sounds like folks criticize haskell (and probably rightly so) for not > having a good definition, so implementations can ethically vary > widely. so which fp actually does have well nailed-down semantics?
Hmm - you've piqued my curiosity - is there something specific about Haskell's semantics that bothers you? Perhaps it's to do with when unforced things may be evaluated?
raould <rao...@gmail.com> writes: > sounds like folks criticize haskell (and probably rightly so) for not > having a good definition, so implementations can ethically vary > widely. so which fp actually does have well nailed-down semantics? > plus a useful-in-the-real-world implementation (or two or three)?
Some of Swierstra's other publications at that site (such as his thesis that I just happened to mention in an unrelated post) touch on similar subjects.
> Hmm - you've piqued my curiosity - is there something specific about > Haskell's semantics that bothers you?
i'm not clueful enough to give a concrete example, but have seen discussions here and in comp.lang.functional where some folks have said what i paraphrased (hopefully w/out changing the message too much). i hazard that it generally has to do with space leaks due to laziness.
> Some of Swierstra's other publications at that site (such as his > thesis that I just happened to mention in an unrelated post) touch on > similar subjects.
they all sound great (i skimmed the Beast one). anybody know if they are actually being implemented in some real-world Haskell implementation? one can dream.
> I'd have guessed that Standard ML probably does?
ja, i would very much like it if this particular slice of the multiverse had some smart effective people making SML++ that would be a conservative clean-up and nailing-down of that language, with perhaps a few important improvements e.g. really good modules or whatever other top issue.
raould wrote: >> Hmm - you've piqued my curiosity - is there something specific about >> Haskell's semantics that bothers you?
> i'm not clueful enough to give a concrete example, but have seen > discussions here and in comp.lang.functional where some folks have > said what i paraphrased (hopefully w/out changing the message too > much). i hazard that it generally has to do with space leaks due to > laziness.
I think the problem with ambiguity wrt space behaviour of Haskell programs isn't so much with laziness. If all Haskell implementations were truely lazy then they should all use the same fully determined reduction order (normal order reduction). Laziness induced space leaks could be nailed using explicit seqs in the program source.
The problem is that normal order reduction can be inefficient, so compilers can change the reduction order provided this does not affect the termination properties. They may use strictness analysis to decide when this is safe, but this is not mandated nor is the algorithm used standardised. As strictness analysis is AFAICS effectively the halting problem in disguise, it has no general solution. Some compilers may well do a better job than others, hence they won't all use same reduction order or exhibit same space behaviour for the same source program. In fact even with the same compiler you may get completely different space behaviour for the same program, depending on optimisation settings.
> I think the problem with ambiguity wrt space behaviour of Haskell > programs isn't so much with laziness. If all Haskell implementations > were truely lazy then they should all use the same fully determined > reduction order (normal order reduction). Laziness induced space leaks > could be nailed using explicit seqs in the program source.
as an aside: reading the Clojure list, i often see people tripped up by laziness there, even w/out the added problem of ambiguous evaluation order iiuc. i think laziness needs to be really stupendously explicit in the ascii sources.
heap on top of that the issue of changing reduction order and oy veh.
|
