From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-24 12:55:56
On Fri, Oct 24, 2003 at 01:23:58PM -0400, David Abrahams wrote:
> Pavol Droba <droba_at_[hidden]> writes:
> > On Thu, Oct 23, 2003 at 11:21:54PM -0400, David Abrahams wrote:
> >> Pavol Droba <droba_at_[hidden]> writes:
> > [snip]
> >> >> ?? We're not talking about making a copy, since the result differs
> >> >> from the input. In general, you pay the same price in functional
> >> >> languages.
> >> >>
> >> >
> >> > So there is realy NO copy performed in Haskell when evaluating the function,
> >> > it is a transformation. And this is much closer to inplace version,
> >> > in C++ then to copy one.
> >> Gimme a break, man! In pure FP languages data is immutable, so
> >> there's no way to make inplace changes. In Haskell you have to go
> >> into a monad to escape this restriction.
> > I know that this discusion is out of topic, quite a bit, but here is my
> > explanation what I mean, when I say, that nothing is copied:
> > Most of modern FP languages, perform the execution in terms of graph-reduction machine.
> > High level syntax is precompiled to a extended version of lambda calculus
> > and this is then executed.
> > State of an execution is represented by a term, which is represented by a graph.
> > This graph is being reduced as the lambda calculi reduction rules are
> > applied.
> > There is nothing like a stack or variables in this representation. So unless
> > some subterm is bound to more then one expression, it can be safetly modified
> > in-place. And thats usualy what is being done.
> This is my last post on the matter:
> Yes, I know that's often what's being done. However, we never
> said the subterm was only going to be bound to one expression.
> You just added that. The two-expression binding case, of course,
> is exactly the one where immutability of data makes a difference
> in safety.
> Over and out
Ok, we were going nowhere. And it was already out of topic anyway.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk