Re: [Fwd: Re: Functional Programming in the Larger or Functional Oriented Software Engineering]

On 3/30/07, Matthew Swank <[email protected]> wrote:
> >
> > Off the top of my head: in many cases, those two restrictions may
> > actually make immutable data structures more desirable, not less.
> > More persistent data means less data copying and thus less time/space
> > resources used.  And immutable data is an extra data invariant that
> > can sometimes simplify memory management; I certainly don't see how it
> > would complicate it.
> >
> > In the end, I think the impact of slim resources or restricted memory
> > management options on the choice of mutable/immutable data will be
> > very circumstance-dependent.  Even if I spent more time thinking about
> > it, I would be hesitant to give a universal answer.  Nonetheless, I
> > expect immutable data structures to win out in the analysis far more
> > often than they are actually used.
> >
> This seems a little too pat. Many functional idioms create an abundance
> of short-lived objects, and in higher order idioms, like function
> composition, a "natural" way of delegating the responsibility of
> deallocating intermediate values eludes me.

It's not immediately clear to me that short-lived objects are harder
to manage than longer-lived ones; in fact, longer-lived ones seem
likely to require more elaborate memory management policies than
objects which are allocated and released within the same body of code.

Higher order idioms are not synonymous with immutable data structures;
they don't have to go hand-in-hand.  I think introducing immutable
data does not necessarily demand automatic memory management, but
adopting a more general functional programming style may.

-- 
Carl Eastlund