On Dec 1, 9:35 pm, Timothy Pratley <[EMAIL PROTECTED]> wrote:
> > The reason is simple - plain mutable variables have no concurrency
> > semantics. What if you closed over a mutable local? Now you have an
> > object with no synchronization, a concurrency mess.
>
> Thanks Rich for the clarification... that makes it immediately obvious
> why using mutable locals is a bad idea in general.
>
> Just to play the devil's advocate, it is theoretically possible to
> detect someone attempting to close over a mutable local as a compiler
> error. But given that such a feature would just allow/encourage
> imperative style, it would be an evil feature. It really comes down to
> a question of enforcing style I believe? :)
>
Well, if there were mutable locals people would reasonably expect to
be able to close over them. Where they are available in Lisps, it's an
idiom e.g. to map a local fn that mutates a local var, when that is
easier/cleaner than a loop. But yes, obviously I've made decisions
about what kinds of programs I want Clojure to encourage :)
Mutation locally is just as hard to reason about as mutation globally,
independent of concurrency. See for example a typical Java for loop
that sets other local vars and contains breaks/returns.
If it takes more thought initially to construct solutions that don't
need variables, please try to expend the effort - it will repay you
many times over. I imagine there are now some Clojure users who can
attest to that.
This whole thread has gotten so icky, and has lost focus on the beauty
and lesson of Stuart's original example.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
