Re: how is Haskell not robust?

Hello Raould

raould wrote:
also, i hope DDC continues on to be something of an in-production-
viable system.
http://www.haskell.org/haskellwiki/DDC

That does look interesting. I haven't looked at it seriously because it
prolly doesn't run on Windows (yet) and doesn't have any real
documentation (we've got to wait for Bens thesis).

as an aside, i wonder if laziness in Concurrent Clean is as much of an
issue as it seems to be in Haskell. i mean, i would expect that if it
is confusing it would be so in general.

Yes, Clean has does have more or less the same problems in principle,
but I think Clean semantics are more precise as they're defined directly
in terms of graph rewriting, not lambda calculus (as in Haskell). So
(assuming graph rewriting is the underlying implementation in both
cases) Clean gives more control over issues like sharing and space leaks
than Haskell does.

eg. If at the top level I have something like this..

-- The list of all primes in ascending order
primes :: [Integer]
primes = <some cute expression>

In a Haskell implementation this is likely a constant graph (and
probably a space leak). I forget the precise Clean syntax, but Clean
gives you the choice of having primes as a constant graph or as a
"function of zero arity". In the latter case you get a new list of
primes every time the value of primes is demanded.

The other old example I'm reminded of is the power set function (set of
all subsets):

-- Huge space leak, even if result is consumed and discarded as a lazy
-- list.
powerset :: [a] -> [[a]]
powerset [] = [[]]
powerset (x:xs) = xss ++ map (x:) xss
| where xss = powerset xs

-- No huge space leak *provided* the result is consumed and discarded as
-- a lazy list. Otherwise slower and even more memory hungry.
powerset :: [a] -> [[a]]
powerset [] = [[]]
powerset (x:xs) = powerset xs ++ map (x:) (powerset xs)

This example is interesting in that it shows that that often there is no
single obvious "best" definition of some function. Bestness is a non
local property and depends on context of use. So this kind of implies
whole program (or whole something) analysis is needed for a smart
compiler to synthesise the "best" implementation.

Also as the whole issue of sharing is somewhat ambiguous in Haskell
there's no guarantee that common sub-expression elimination will not
transform the second into the first in any case (though I believe no
current implementation would actually do this).

Regards
--
Adrian Hey


.

Relevant Pages

  • Re: how is Haskell not robust?
    ... an issue as it seems to be in Haskell. ... Yes, Clean has does have more or less the same problems in principle, ... If the sharing semantics were specified ... -- The list of all primes in ascending order ...
    (comp.lang.functional)
  • Re: how is Haskell not robust?
    ... an issue as it seems to be in Haskell. ... Yes, Clean has does have more or less the same problems in principle, ... -- The list of all primes in ascending order ... probably a space leak). ...
    (comp.lang.functional)
  • Re: Clean
    ... smart question of the Haskell community, you will probably get a helpful answer. ... It seems as if, as Haskell has grown more popular as a language, at ... While the authors of Clean profit from time to time from Haskell formal ...
    (comp.lang.functional)
  • Re: how is Haskell not robust?
    ... of an issue as it seems to be in Haskell. ... If the sharing semantics were specified ... -- The list of all primes in ascending order ... Uses Omemory, no matter which prime you pick by index. ...
    (comp.lang.functional)
  • Re: Chez Watt: Prime Idiocy
    ... clean, but you kept pressuring on that point, so I slopped it out. ... "primes" if you haven't got a clue what you are talking about. ... Do something today about the Darfur Genocide ...
    (talk.origins)