On Dec 29, 2:29 pm, "Mark Engelberg" <mark.engelb...@gmail.com> wrote:
> 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.
People who know what they are doing can do these things right now with
Clojure's array support. There really isn't any more value for Clojure
to add to that, so no special primitives. I fully accept the necessity
of doing that at times, and the correctness of internally mutating,
but externally referentially transparent functions, and Clojure has
several of them. That's one of the reasons Clojure isn't 'pure'. OTOH
it's not a good argument for mutable local vars. What other "unsafe
things" are you looking for?
People could have used j.u.c.atomic also, but atom provides a unified
interface consistent with the other reference types, and using swap!
encourages a race-free discipline most people wouldn't pursue with
plain mutable locals and often get wrong with CAS.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
