Re: is laziness leakier?
Nobody
> In any event, despite the fact that it is no longer the language du
> jour I still like SML better - becuase I like strictness better.
I suspect that you mean "eagerness".
Strict vs non-strict is an issue of semantics. Lazy vs eager is an
implementation issue.
It's possible to make use of eager evaluation in a language with
non-strict semantics, but you have to be careful (i.e. only use it if you
can determine that it is safe to do so).
> Functional languages are supposed to be higher-order. You program
> using high-level abstractions and let the compiler and/or run time
> worry about low-level things like memory management. Laziness seems to
> create a leak in the abstraction that allows underlying memory issues
> to surface. Maybe this is an example of Joel Splosky's "Law of Leaky
> Abstractions": All non-trivial abstractions, to some degree, are leaky
> ( http://www.joelonsoftware.com/articles/LeakyAbstractions.html ). Is
> my intuition correct or am I just displaying a newbie's ignorance?
I think you are correct here. If a language's semantics don't consider
memory usage, then the language's notion of equivalence doesn't count for
anything when memory usage is significant.
But this is actually true to some extent of most high-level languages. If
you read the specifications for e.g. Java or Python, as soon as you get
beyond the language primitives and a handful of core classes, information
on factors which can affect memory consumption tends to become quite
scarce.
OTOH, at least in Haskell the "leaks" tend not to affect the end result
(unless the program simply fails due to lack of memory). The same is
seldom true for languages with mutable state. E.g. in an OO language, a
method which modifies the object's state may call down to other methods as
part of the process. The odds are that the object's state at that point
will be entirely undocumented and often contradicting stated invariants.