On Mon, Dec 29, 2008 at 8:05 AM, Rich Hickey <richhic...@gmail.com> wrote:
> It is certainly not the whole point of Clojure to make as much code as
> possible safe for its software transactional memory. Clojure is a set
> of tools. They are designed to allow for robust programs to be built,
> including multithreaded programs. STM is one of those tools, but is
> not a universal answer.

It's good to hear you say this, because I agree.  I was "dispensing
advice" based on my perception of your philosophy (and because I sense
from discussions that most people are assuming atoms are safe in ways
they really aren't).  But in fact, I think that Clojure's tools for
mutability don't yet go far enough, and I'd prefer to have a few more
"unsafe" things in the toolbox for experienced programmers.

For example, mutability is extremely useful for
constructing/initializing complex data structures, especially ones
that have cyclic references.  (Or think about how StringBuffer is used
to set up a string with mutability, and then it is delivered as an
immutable String).  Also, mutability of local variables can be handy
when implementing a complex "classic" algorithm that is described as a
sequence of imperative steps, in order to keep the form of the code as
close as possible to the source.

This sort of local mutability has no impact on referential
transparency, and is really quite safe when used properly.  But none
of the existing types of mutability seem like a good fit for this
need.  It seems like overkill to have to use a ref or atom with their
transaction or swapping syntaxes in order to mutate something that
will never be observed as mutable by the outside world.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to