Today, I have released new versions of all the packages currently
included in the Closer Project - see
http://common-lisp.net/project/closer/ for the project and
http://p-cos.blogspot.com/2006/01/closer-project-new-releases.html for
the announcement.
This project is an umbrella project for a few subprojects whose aim is
to improve the usability of the CLOS MOP across different Common Lisp
implementations. It is also the home of ContextL, a full-fledged CLOS
extension in its own right providing language constructs for
Context-oriented Programming (COP).
All packages now support the current versions of all supported Common
Lisp implementations. They are:
� Allegro Common Lisp 7.0 Enterprise Edition.
� Allegro Common Lisp 8.0 Enterprise Edition.
� CLisp 2.35 - 2.37
� CMU Common Lisp 19c
� LispWorks 4.4.5, 4.4.6 for Macintosh, Personal Edition
� LispWorks 4.4.5, 4.4.6 for Macintosh, Professional Edition
� Macintosh Common Lisp 5.1
� OpenMCL 1.0
� SBCL 0.9.7, 0.9.8
Highlights of the new versions.
MOP Feature Tests 0.4:
� All previous known but untested problems have either been resolved or
turned into actual tests.
� Added a test for checking whether the slot order requested by a
primary method for COMPUTE-SLOTS is honored by a MOP. (Thanks to
Christophe Rhodes for the suggestion.)
� Added a test for checking whether the object returend by
COMPUTE-DISCRIMINATING-FUNCTION can be funcalled and whether the second
parameter to SET-FUNCALLABLE-INSTANCE-FUNCTION can be a 'real' closure.
� Added a test for checking whether one can use one's own :ALLOCATION kinds.
� Added a test for checking whether a generic function without any
methods defined can still be called.
� Added a test for checking whether a DEFMETHOD form can have multiple
qualifiers.
� Added more fine-grained tests for checking SLOT-XXX-USING-CLASS functions.
� Added a test whether REINITIALIZE-INSTANCE on a class metaobject calls
FINALIZE-INHERITANCE. Luckily, all implementations pass that test.
Closer to MOP 0.3:
� The supported Common Lisp implementations improved with regard to
their support for the MOP, with varying extent. This required a few
changes here and there.
� The lack of extensible :ALLOCATION kinds in Allegro Common Lisp, as
specified in AMOP, is fixed. Thanks to John Foderaro for giving me the
important hint on how to solve this.
ContextL 0.2:
� When rebinding special places, it is now checked whether they actually
contain special symbols, so this is now a safe operation. This can be
tweaked to omit the check for improved performance.
� Changing a non-special slot to a special slot in an already existing
class is now also supported in Allegro Common Lisp from 7.0 on. Thanks
to Duane Rettig for fixing the related bug in Allegro and thereby
enabling this feature.
� Improved parsing of layered methods: The :METHOD option in
DEFINE-LAYERED-FUNCTION is now parsed and processed correctly.
Furthermore, one can now optionally give a name to the otherwise
anonymous layer parameter. This is useful for calling CALL-NEXT-METHOD
with changed parameters.
� Added a new namespace for layers. Before, their names could
accidentally clash with class names.
� Added a number of performance tweaks and better error messages.
� Fixed a few bugs.
Special thanks go to John Foderaro, Duane Rettig and Christophe Rhodes
(in alphabetical order) for exceptional help.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> • Improved parsing of layered methods: The :METHOD option in
> DEFINE-LAYERED-FUNCTION is now parsed and processed
> correctly. Furthermore, one can now optionally give a name to the
> otherwise anonymous layer parameter. This is useful for calling
> CALL-NEXT-METHOD with changed parameters.
w00t! I've been bit by this one a few times.
> • Added a new namespace for layers. Before, their names could
> accidentally clash with class names.
w000t! i'd already coded around this one :)
I've learned a lot from playing with ContextL and reading your code,
thanks for that.
What i'd like to know is, is there anyway to capture the current state
of the layer stack and restore it at a later time? Or, alternately,
another method of having layers play nice with UCW and call/cc.
I suppose i should join the mailing list, but i'm doing c.l.l today :)
drewc
> Pascal
>
> --
> My website: http://p-cos.net
> Closer to MOP & ContextL:
> http://common-lisp.net/project/closer/
--
drewc at tech dot coop
drewc wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>• Improved parsing of layered methods: The :METHOD option in
>> DEFINE-LAYERED-FUNCTION is now parsed and processed
>> correctly. Furthermore, one can now optionally give a name to the
>> otherwise anonymous layer parameter. This is useful for calling
>> CALL-NEXT-METHOD with changed parameters.
>
> w00t! I've been bit by this one a few times.
Me too. ;)
>>• Added a new namespace for layers. Before, their names could
>> accidentally clash with class names.
>
> w000t! i'd already coded around this one :)
I haven't thought of this in the previous version - but this is Common
Lisp, so it should be like that.
> I've learned a lot from playing with ContextL and reading your code,
> thanks for that.
You're welcome. Thanks for using it and mentioning it in your
presentation...
> What i'd like to know is, is there anyway to capture the current state
> of the layer stack and restore it at a later time? Or, alternately,
> another method of having layers play nice with UCW and call/cc.
Currently, there is no way to capture the current list of active layers,
but I have an idea how to implement this. I can't promise that I will
implement this very soon, but sometime in the first half of this year is
realistic. It's good to hear that someone actually asks for this because
until now, I have seen this particular feature only as an intellectual
exercise, so to speak.
There are also some other cool ideas lying around, like a metacircular
implementation of layer activation which should give you some means to
influence what happens in detail when layers are switched. So there is
more to come...
> I suppose i should join the mailing list, but i'm doing c.l.l today :)
I'd prefer the mailing list for more indepth discussions, but c.l.l is
also fine for me.
Cheers,
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> drewc wrote:
>
>> What i'd like to know is, is there anyway to capture the current state
>> of the layer stack and restore it at a later time? Or, alternately,
>> another method of having layers play nice with UCW and call/cc.
>
> Currently, there is no way to capture the current list of active layers,
> but I have an idea how to implement this. I can't promise that I will
> implement this very soon, but sometime in the first half of this year is
> realistic. It's good to hear that someone actually asks for this because
> until now, I have seen this particular feature only as an intellectual
> exercise, so to speak.
Wait, are you using special slots? If not, this may actually be
relatively straightforward: The list of active layers is represented in
the variable contextl::*active-context*, so capturing the current layers
and restoring them later may be as simple as reading and writing that
variable. I haven't thought this through, so I can't guarantee that this
works without problems, but you may want to experiment with this. If so,
let me know what comes out of this.
Cheers,
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Pascal Costanza wrote:
>> drewc wrote:
>>
>>> What i'd like to know is, is there anyway to capture the current state
>>> of the layer stack and restore it at a later time? Or, alternately,
>>> another method of having layers play nice with UCW and call/cc.
>> Currently, there is no way to capture the current list of active
>> layers, but I have an idea how to implement this. I can't promise
>> that I will implement this very soon, but sometime in the first half
>> of this year is realistic. It's good to hear that someone actually
>> asks for this because until now, I have seen this particular feature
>> only as an intellectual exercise, so to speak.
>
> Wait, are you using special slots?
I'm not. Basically the only feature i'm using is layered-methods,
although i've defined all the classes as layered, i have yet to
actually do anything with that.
My usage of contextL is quite simple. In the Original LoL, i had a lot
of methods like :
(defmethod present-slot ((slot string-slot) instance)
(cond ((editablep slot)
(;; render slot as editable))
((linkedp slot)
(;; render slot as link)))
[...])
... which gets old quickly,and is hardly user extensible.
I was about halfway to inventing ContextL when
i first read you paper :).
now, i use layers for all this, and i really helps clean things up. In
the new LoL , which is much more of a DSL (i've named the language
Lines on Lisp), things are much simpler.
(defattribute string-attribute ()
()
(:type-name string))
(defdisplay string (:description (attribute string-attribute))
(;; render as normal))
(defdisplay string (:description (attribute string-attribute)
:in-layer editor)
(;; render as editor)
(defdisplay string (:description (attribute string-attribute)
:in-layer link
:combination :around
:component c)
(with-inactive-layers (link) ;avoid-nested-links
(<ucw:a :action (call-display c string)
(call-next-method))))
which, when put all together (with a lot more stuff) could look like :
(with-active-layers (as-table)
(display* (select-instances 'person t)
:type 'one-line
:layers '(+ link)
:attributes '(first-name last-name company-name)
:link '(:type editor)))
will display a list of persons, which each person in a table row, with
each row having a link to a person editor.
The problem i'm trying to solve now is that CALL-DISPLAY is an
'action', which in UCW parlance means a cps transformed function. The
layers that are currently active will not be so when the action is
actually run (when that link is clicked), i need to capture that state
somehow.
> If not, this may actually be
> relatively straightforward: The list of active layers is represented
> in the variable contextl::*active-context*, so capturing the current
> layers and restoring them later may be as simple as reading and
> writing that variable. I haven't thought this through, so I can't
> guarantee that this works without problems, but you may want to
> experiment with this. If so, let me know what comes out of this.
I'll play around with it, and probably post to the mailing list once i
run into a road block.
One more thing i was thinking of would be mutually exclusive layers,
where activating a layer would de-activate another which would be
restored once the other layer is no longer active.
For example, an editable slot (which is usually an INPUT tag) should
probably not be wrapped in an <a/>, so activating the editor layer
should deactivate the link layer. and vice-versa.
Is something like this possible now? If not, could it be possible?
Thanks again.
drewc
>
>
> Cheers,
> Pascal
>
> --
> My website: http://p-cos.net
> Closer to MOP & ContextL:
> http://common-lisp.net/project/closer/
--
drewc at tech dot coop
drewc wrote:
> My usage of contextL is quite simple. In the Original LoL, i had a lot
> of methods like :
>
> (defmethod present-slot ((slot string-slot) instance)
> (cond ((editablep slot)
> (;; render slot as editable))
> ((linkedp slot)
> (;; render slot as link)))
> [...])
>
> ... which gets old quickly,and is hardly user extensible.
>
> I was about halfway to inventing ContextL when
> i first read you paper :).
>
> now, i use layers for all this, and i really helps clean things up. In
> the new LoL , which is much more of a DSL (i've named the language
> Lines on Lisp), things are much simpler.
Thanks - nice example.
> The problem i'm trying to solve now is that CALL-DISPLAY is an
> 'action', which in UCW parlance means a cps transformed function. The
> layers that are currently active will not be so when the action is
> actually run (when that link is clicked), i need to capture that state
> somehow.
>
>>If not, this may actually be
>>relatively straightforward: The list of active layers is represented
>>in the variable contextl::*active-context*, so capturing the current
>>layers and restoring them later may be as simple as reading and
>>writing that variable. I haven't thought this through, so I can't
>>guarantee that this works without problems, but you may want to
>>experiment with this. If so, let me know what comes out of this.
>
> I'll play around with it, and probably post to the mailing list once i
> run into a road block.
OK, I am relatively sure that saving contextl::*active-context* should
do the job. I hope I can provide a cleaner interface for this in the
near future...
> One more thing i was thinking of would be mutually exclusive layers,
> where activating a layer would de-activate another which would be
> restored once the other layer is no longer active.
>
> For example, an editable slot (which is usually an INPUT tag) should
> probably not be wrapped in an <a/>, so activating the editor layer
> should deactivate the link layer. and vice-versa.
>
> Is something like this possible now? If not, could it be possible?
It's not possible now, but it will be possible in the future. The
metacircular layer activation will allow you to express these things (if
all goes well, that is... ;)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/