*
To be removed from from further mailings respond to
this message with remove in the subject line.
*
Dear Friend,
Discover how you can accept credit cards directly
from your
I don't want to seem incredibly Luddite, but there are some things the World Wide
Web is not good at, and one of them is permanence. Try for example finding out
about Glasgow Haskell from http://www.dcs.gla.ac.uk, which was I think the
standard URL a few years ago. In 2050 we may not even have
I find it therefore of concern that many crucial Haskell documents,
including the standard and, for example, the various Glasgow Haskell
manuals, are only available online.
My printed copy of the Haskell 98 report is numbered:
YaleU/DCS/RR-1106
Copies can no doubt be obtained from the
We're not really in a position to mail out bound copies of the Haskell
report. We generally distribute our tech reports in electronic form
and haven't even been asked for paper copies in years. I've got a few
bound Haskell reports that I give to visitors but we don't plan to
print any more. It
Alastair David Reid wrote:
I find it therefore of concern that many crucial Haskell documents,
including the standard and, for example, the various Glasgow Haskell
manuals, are only available online.
My printed copy of the Haskell 98 report is numbered:
YaleU/DCS/RR-1106
[snip]
I've been working with one pecular algebraic data structure,
named Register, which is described in currently upgraded
http://www.numeric-quest.com/haskell/QuantumComputer.html.
or in gzipped version of the same document
Alastair David Reid wrote:
Executive summary: David's program has an incredibly subtle space leak
in it (or I'm being incredibly dumb). I encourage the honchos (and
would be honchos) to have a look. Users of other compilers might give
it a shot too.
David Bakin wrote:
Why is there a
This whole discussion seems strange...
Is laziness an operational or a semantic issue?
Why can't haskell implementations reduce some expressions to save space?
In particular, why can't haskell mark expressions that grow after
evaluation, and reduce them if too much space is being consumed.
For
On Tue, 5 Jun 2001, Tom Moertel wrote:
The reason that foo1 leaks space is because the middle of v grows
faster than its head. So taking elements from v causes its in-memory
footprint to grow. To see why this is the case, evaluate foo1 by hand:
So the problem isn't Hugs but rather the
Wojciech Moczydlowski, Jr wrote:
How come then that the very program compiled under nhc98 evaluates without
any problem, with memory usage below 1M during its execution?
My claim was that v (as defined) grew faster than it could be consumed,
not that (length (foo1 n)) couldn't be evaluated
Tom,
I noticed this post after I had just posted my own response.
You have to realize that Alastair Reid is one of the truly
great Haskell programmers on planet earth. I'm serious.
So, when he says incredibly subtle space leak I wouldn't
expect the solution to be simple. As far as I can
I'd love it if someone could write a tutorial paper on space leaks. Even with the
explanations that have been provided, I find it difficult to understand why
expressions get evaluated in a particular order and why garbage collections happen at
a given point.
Dominic.
Alastair David Reid wrote:
Executive summary: David's program has an incredibly subtle space leak
in it (or I'm being incredibly dumb). I encourage the honchos (and
would be honchos) to have a look. Users of other compilers might give
it a shot too.
I think there have been several
Tom Moertel wrote:
Mark Tullsen wrote:
You have to realize that Alastair Reid is one of the truly
great Haskell programmers on planet earth. I'm serious.
So, when he says incredibly subtle space leak I wouldn't
expect the solution to be simple.
Whoops. Now don't I feel foolish.
14 matches
Mail list logo
