Re: Combining mutable objects with const references

anonposting@[EMAIL PROTECTED]
 writes:
> If there is a situation where persistence is required and can only
> be achieved efficiently ("minimizing copying") with a special data
> structure, then the imperative programmer can use that special data
> structure. He always has as many options as the functional
> programmer, structure-wise.

The functional programmer can similarly use mutable structures by
organizing the code so that the mutations can be modelled as actions
computed by function evaluation.  You basically treat the mutable
structure as if it were an I/O device.  The Haskell IO Array monads
are examples of this.  Using them is considered a bit icky since most
of the time they don't gain you much and it's better to use functional
structures, but the mutable versions are there if you need them, yet
the language still ensures that the messiness involved doesn't spread
outside of the limited scope that is actually typed to use the moand.

On a meta level, the notion that adding features to a language makes
it more capable is tempting but bogus.  Adding feature X might give
you the freedom to do X, but maybe what you really want is freedom
-from- X.  E.g., if your language has untyped memory pointers like C
or assembler, there is a huge class of bugs that your programs are no
longer necessarily free of.  Languages have to do more than ensure
that you can implement various desired program behaviors.  They also
should let you ensure the absence of undesired behaviors.  So good
language design is a balancing act of removing powerful but dangerous
features, and then using extreme cleverness (such as functional data
structures) to let you still accomplish your programming tasks with
what is left over after the dangerous stuff is removed.