[closer-devel] Efficiently composing layers in contextl
Pascal Costanza
pc at p-cos.net
Sun Feb 9 13:48:27 UTC 2014
On 9 Feb 2014, at 14:14, Dan Lentz <danlentz at gmail.com> wrote:
> ContextL remains a favorite of mine and as I've recently been doing some work in Clojure I naturally started thinking about if/how "context orientation" might fit into the (very different) clojure universe and culture. I'm not sure it would be a popular idea actually I considered the clojurians might throw tomatoes at me for bringing it up... Largely I think it would be focused on the idea of dynamically composable contexts for dispatch of multifunctions -- or something similar. The layers and layered functions are largely what I have wound up using in ContextL; I haven't gotten many cases to use layered objects.
I’m glad that you like ContextL. It’s always nice to hear about happy users. :)
I can imagine that ContextL-like features would actually be ok in the Clojure community. Rich Hickey was actually aware of ContextL when he designed the first versions of Clojure, and it was a motivation for him to add dynamic scoping to Clojure. See for example the transcript of a talk given in 2008 at http://jafingerhut.github.io/clojure-info/clojure-for-lispers-transcript.txt - to quote: “[…] all Clojure functions are defined with def, they're all stored in dynamic Vars, which means you can dynamically bind functions in nested contexts. That's really cool. If you've been into ContextL or aspect oriented programming, you can do that with Clojure out of the box because of this behavior. Because functions are stored in Vars, you can rebind them in context. If you want to, in a particular context, add logging to a function, you can do that. Change its behavior, swap out the algorithm, because you know the data set is going to be unusual in this call context, totally doable. It's very powerful stuff. And it sort of fell out of it. It's easy.”
I’m not quite sure about the “out of the box” part, though, as you can imagine… ;) He probably refers more to our work on dynamically scoped functions that was a precursor to ContextL, which is a much simpler idea and much easier to implement if you have dynamically scoped variables.
> So in dreaming up ways to model layers I started to consider the Patricia trie, which is an efficiently mergeable integer map. Thus, layers could be dynamically composed very quickly. I know a major performance cost in ContextL is in composing the layers (after which they are cached and after the first use of a context, access is quite efficient). So my question is, has anyone considered such an alternative means of modeling layers in ContextL and if so, what were the detractions that led you to dismiss the idea?
No, I haven’t considered such a data structure when I implemented ContextL. The current implementation was based on the idea to take as much advantage of the existing dispatch in CLOS as possible, and creating these context hierarchies on the fly by basing them on dynamically created class metaobjects that inherit from each other was just the simplest way of doing this. I believe the other implementations for context-oriented programming (in Smalltalk, Java, and some other smaller implementations) are actually still even simpler and considerably less efficient, because they traverse the context hierarchy on every method call.
I haven’t been aware of Patricia tries. It would be very interesting to hear more about this if you can make this work. This sounds to me like an idea that could even be worth publishing about in academic conferences or papers. (At least at the dynamic languages symposium (DLS), or ILC / ELS or some Clojure conferences.)
> I actually don't have a pressing need for context-oriented clojure. This is more of just a concept I've been playing with because my experience with ContextL has been so positive.
If you want to bounce some more concrete ideas off, feel free to do so. I’m very curious about this.
Pascal
--
Pascal Costanza
More information about the closer-devel
mailing list