Hi everybody,
Ed wants to make the naming conventions more consistent, to make the
various destructive and non-destructive operations more
'discoverable'. I want to propose a more radical approach.
First of all, at some point in the future, perhaps (optimistically) a
year from now, Factor will get 'real' concurrency and scalability
across multi-core CPUs via native threading. As some people are aware,
getting concurrent code right can be difficult, especially if a lot of
state is shared. I won't be going for a shared-nothing approach as in
Erlang; we'll have message passing, but also STM, futures, promises,
as well as lower-level abstractions such as locks. So we'll want to
minimize sharing of mutable objects between threads.
So I propose that when we move to native threading, we also move to
immutable collections. The Clojure language for the JVM
(http://clojure.org) implements very efficient vectors and hashtables
where operations return new objects (which share some of the structure
with the original) without mutating anything. Adding elements at the
end of a Clojure vector is O(1) and random access is O(log_32 n);
similarly for the hashtables. This is entirely acceptable in my eyes,
and Rich Hickey, the author of Clojure, even claims that his
collections beat Java's built-in ArrayList and HashMap on some
benchmarks.
So if mutable vectors went away, we wouldn't need push, push-all,
delete-nth, and so on. Mutable fixed-length arrays would remain, and
tuples would be mutable too, so there would be some mutating
operations left, but the notion of a resizable sequence would go away.
Right now a common idiom is to store a vector in a variable, then get
the variable value and push on it. In the world of immutable vectors,
this would be facilitated by having a 'ref' tuple type,
TUPLE: ref value ;
so instead of doing
foo get push
you'd do
foo get [ suffix ] change-value
I have already implemented Clojure's persistent-vector in Factor, you
can find it in extra/. Eventually I'll implement persistent
hashtables, trees, dequeues and priority queues too. So people will be
able to start using these right away.
However I want to emphasize that such a radical change to the core
language won't happen for at least a year, if at all. But it is
something to keep in mind, along with the eventual move towards native
threading and more concurrency-safe abstractions.
Slava
|
