John Nagle wrote:
Python's concept of immutability is useful, but it could be more
general.
In the beginning, strings, tuples, and numbers were immutable, and
everything else was mutable. That was simple enough. But over time,
Python has acquired more immutable types - immutable sets and immutable
byte arrays. Each of these is a special case.
Python doesn't have immutable objects as a general concept, but
it may be headed in that direction. There was some fooling around
with an "immmutability API" associated with NumPy back in 2007, but
that was removed. As more immutable types are added, a more general
approach may be useful.
Suppose, for discussion purposes, we had general "immutable objects".
Objects inherited from "immutableobject" instead of "object" would be
unchangeable once "__init__" had returned. Where does this take us?
Immutability is interesting for threaded programs, because
immutable objects can be shared without risk. Consider a programming
model where objects shared between threads must be either immutable or
"synchronized" in the sense that Java uses the term.
Yes, this is one of the reasons I am currently learning Haskell, I am
not yet anywhwere near proficient but the reason I am looking into FP is
because of some of the claims of the FP community, particularly Erlang,
regarding the benefits of pure FP with respect to multi-threading.
It's a shame this post came right now since I'm not really up-to-speed
enough with Haskell to comment on it with repsect to multi-threading.
<context>
I program Perl, Java and C++ for my day job, I've spent a lot of time
making multithreaded programs work correctly and have even experienced
the POE on a large project. So my comments below are based on experience
of these languages.
</context>
> Such programs are free of most race conditions, without much
> programmer effort to make them so.
I disagree. They are not free of most race conditions, and it still
takes a lot of effort. Where did you get this idea from? Have you been
reading some Java primer that attempts to make it sound easy?
Java "synchronized" turned out to be a headache partly because
trying to
figure out how to lock all the "little stuff" being passed around
a headache. But Java doesn't have immutable objects. Python does,
and that can be exploited to make thread-based programming cleaner.
This is nothing to do with Java, any multithreaded language that has
mutable shared state has exactly the same problems. Can we talk about
threading rather than Java please? Additionally Java provides a lot more
than monitors (synchronized) for controlling multiple threads.
Java does have immutable objects. Strings in Java are immutable for
example. As are the object-based numeric types, Bytes, Characters etc.
There are lots and lots of immutable types in Java and you can make your
own by creating a class with no mutator methods and declaring it "final".
The general idea is that synchronized objects would have built in
locks which would lock at entry to any function of the object and
unlock at exit. The lock would also unlock at explicit waits. A
"Queue" object would be a good example of a synchronized object.
With this mechanism, multi-thread programs with shared data
structures can be written with little or no explicit locking by
the programmer. If the restrictions are made a bit stricter,
strict enough that threads cannot share mutable unsynchronized data,
removal of the "global interpreter lock" is potentially possible.
This is a route to improved performance on modern multi-core CPUs.
Right, this is where I would love to have had more experience with Haksell.
Yes, as soon as you get to a situation where no thread can access shared
state that is mutable your problems go away, you're also getting no work
done becasue the threads, whilst they may be performing lots of
interesting calculations have no way of allowing the rest of the
program, or operating system, know about it.
You can, today, in any language that provides threads, make any number
of threaded programs that do not contain any race conditions, it's just
that most of them are terribly dull and uninteresting.
I'd love for someone from the Haskell/Erlang/<other> pure FP community
provide some canonical example of how this is acheived in pure FP. I'll
get there soon but I'm not going to skip ahead in my reading, I'm still
trying to learn the basics.
So, in response to your point of trying to get an immutable API so that
Python can easily have multi-threaded programs that do not present race
conditions I would say the following:
That is not the challenge, that's the easy part. The challenge is
getting useful information out of a system that has only been fed
immutable objects.
Regards,
Nigel
--
http://mail.python.org/mailman/listinfo/python-list
