Context-dependent behavior is becoming increasingly important for a wide
range of application domains. Unfortunately, mainstream programming
languages do not provide mechanisms that enable software entities to
adapt their behavior dynamically to the current execution context. In
collaboration with various researchers, we have developed a new
programming technique called "Context-oriented Programming" (COP).
ContextL - http://common-lisp.net/project/closer/contextl.html - is our
first fully implemented and currently most mature programming language
extension for COP and is built on top of the Common Lisp Object System
(CLOS). ContextL has first been made available to the public in early
2005, and has already been adopted by a number of programmers. We would
now like to assess how well ContextL has been received so far.
Please consider participating in our first survey about ContextL - this
will help us a lot to develop ContextL and related projects further
(like Closer to MOP, etc.).
You can find the survey and more information about it at
http://prog.vub.ac.be/~pcostanza/COP/survey.html
Thanks a lot,
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Although I can't admit to having actually used this technology, I find
it quite interesting (along with aspect-oriented and subject-oriented
programming) and your 2005 paper, with Hirschfeld, is an eloquent
explication. I have wondered for some time about potential cross-
fertilization between these various programming paradigms and the set
of similar cognitive knowledge/concept paradigms. Historically, of
course, these were closely related: The concept of frames came from
Minsky, and was transported directly into AI, and elaborated into
hierarchies of knowledge representation by Bobrow, Fahlman, Brachman
and others. And, of course, those concepts influenced cognitive
science as well, via crossover from AI: Simon and Newell, Anderson,
Bobrow and Norman and others. But for some time -- probably 20 years
or more -- these domains have developed more-or-less separately so
that concepts from cognitive science have not been closely related to,
and have not found their way back into AI, and more particularly for
the present case, programming methodology. The examples that I think
of particularly are the cognitive mechanisms that surround the
incremental formation of concepts: analogy, instantiation, conceptual
blending, and view application. These differ from one another in many
subtle (and some not-so-subtle) ways, and are more-or-less similar to
programming methodologies. Instantiation, for example, maps fairly
directly into programming methodology: You have an abstract
description/program/object and you instantiate it into a concrete one
which either functions directly in the base domain, or can be further
instantiated until, finally, you reach a fully instantiated image, at
which point you can run it (if there's anything left to run - the
limit of this process being full lazy evaluation!) Analogy does not
have, as far as I can tell, an analog (pardon the pun) in programming.
Here one would do something like creating a new function from another
function, changing some things along the way to fit the new domain. Of
course, programmers do this explicitly all the time, but I don't know
of any programming methodology that accords with this description. I
think that Aspect, Subject, and Context oriented programming (and,
indeed, multiple inheritance, and to some extent database views) are
trying to do what cognitive scientists call either Conceptual Blending
(CB) or View Application (VA). These both have the same effect,
although they reach it through (possibly) different paths. The effect
is what amounts to combining two or more concepts into a new one that
inherits some properties from one and some from the other(s). How
specifically the mixing takes place, and what to do when there are
conflicts is usually domain specific. What differentiates CB from VA
is just that CB takes concepts that are supposed to be more-or-less at
the same level of abstraction (e.g., computer + calculator =>
programmable calculator), whereas VA always takes a concrete object
and wraps an abstraction over it, creating a new concrete object
combined with the abstraction. (E.g., programmable + calculator =>
programmable calculator; the abstract is said to be the "view", thus:
"view application".) Note that "concrete" v. "abstract" are themselves
slippery concepts; concrete models can have variable terms. This is
partly why I name CB and VA in the same breath; I'm not sure that they
are fundamentally distinct. The idea of VA (or CB) is that one can
"view" something "in terms of" another thing (the "view"). This is a
little like a database view, but the "abstraction" (view) in that case
is the SQL query that builds the new (virtual) table. And thus seems
as well to be the goal of Context-oriented as well as Aspect-oriented
programming (and possibly subject-oriented programming). Indeed, VA
probably has the same intuitions behind it as Aspect-oriented
programming, and might well have come from the same common source,
esp. given the name "aspect" is so close to "view", but VA appears
much earlier than AOP, arriving in cognitive science around 1985, the
same time as CLOS! And the other concepts, esp. analogy, are much
older than even the general idea of object oriented programming.