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 ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
