From pc at p-cos.net  Fri Feb  3 01:11:46 2006
From: pc at p-cos.net (Pascal Costanza)
Date: Fri, 3 Feb 2006 02:11:46 +0100
Subject: [closer-devel] [ANN] New versions of Closer libraries + AspectL
Message-ID: <77E6E6BE-7E19-448F-8DF4-CED0630D2937@p-cos.net>

New versions of the libraries in the Closer Project have been  
released, including the Closer to MOP compatibility layer for the  
CLOS MOP and the ContextL extension for Context-oriented Programming.

Furthermore, AspectL has been moved to the Closer Project, with its  
new version 0.7. Previously, it was an independent project that I  
haven't maintained anymore. Now that bitrot has started to increase,  
I have ported it to the Closer to MOP layer which turned out to be a  
surprisingly smooth process. This especially means that the number of  
Common Lisp implementations that it runs on has increased.

Two bugs in Allegro Common Lisp that have led to problems in  
conjunction with AspectL have also been fixed in the meantime: A bug  
that has prevented a non-special slot to be turned into a special  
slot has been fixed in Allegro 7.0 and 8.0, and the limitation that a  
defmethod form doesn't accept more than one qualifier has been fixed  
in Allegro 8.0. Allegro Common Lisp 8.0 now supports the full  
functionality of AspectL.

Furthermore, the following changes have been made to AspectL:

- Some of the functionality was previously ported from AspectL to  
ContextL, mostly because it is not genuine aspect-oriented  
functionality. Those parts are now removed from AspectL  
implementation-wise in order to avoid code duplication. Instead,  
AspectL imports that functionality from ContextL, and exports it  
again for compatibility reasons. Existing AspectL code should mostly  
work as before.

- Likewise, the CLOS MOP wrappers are completely removed because  
Closer to MOP supports compatibility across different CLOS MOP  
implementations much better.

- Finally, the package structure is much simplified. Instead of  
placing every functionality in its own package, there is now the  
(previously already available) ASPECTL package from which everything  
can be imported. The previous scheme was too complicated and offered  
no obvious advantages.

See http://common-lisp.net/project/closer/ for the Closer Project and  
http://common-lisp.net/project/closer/aspectl.html for AspectL.

Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium






From nickb42 at gmail.com  Mon Feb 20 13:52:07 2006
From: nickb42 at gmail.com (Nick Bourner)
Date: Mon, 20 Feb 2006 13:52:07 +0000
Subject: [closer-devel] Layered function troubles
Message-ID: <17e6dce0602200552o55f31eecy8d59ffc0716fcbb@mail.gmail.com>

Hi all,

I'm having some troubles getting started with layered functions in ContextL
- I keep getting undefined-function errors when I try to use a layered
function, which I'd expect if I wasn't making the appropriate layer active.
Transcript of a test session shown below. Can someone please tell me what
blindingly stupid mistake I'm making?

BTW I'm using sbcl 0.9.8 on OS X, but I get something similar for OpenMCL as
well.


CL-USER> (require 'contextl)
; loading system definition from /usr/local/lib/sbcl/systems/lw-compat.asdinto
; #<PACKAGE "ASDF1183">
; registering #<SYSTEM #:LW-COMPAT {10E6CB31}> as LW-COMPAT
; loading system definition from /usr/local/lib/sbcl/systems/closer-mop.asd
; into #<PACKAGE "ASDF1185">
; registering #<SYSTEM #:CLOSER-MOP {404E9771}> as CLOSER-MOP
NIL
CL-USER> (use-package :contextl)
T
CL-USER> (deflayer foo-layer ())
#<CONTEXTL::LAYER-CLASS LAYER-CLASS-DEFINERS::|COMMON-LISP-USER::FOO-LAYER|>
CL-USER> (defclass bar () ())
#<STANDARD-CLASS BAR>
CL-USER> (define-layered-method baz :in-layer foo-layer ((obj bar))
                (format t "~&baz primary :in-layer foo-layer~%"))
#<STANDARD-METHOD LAYERED-FUNCTION-DEFINERS::|COMMON-LISP-USER::BAZ|
(LAYER-CLASS-DEFINERS::|COMMON-LISP-USER::FOO-LAYER|
                                                                      BAR)
{40513681}>
CL-USER> (defvar *b* (make-instance 'bar))
*B*
CL-USER> (with-active-layers (foo-layer)
       (baz *b*))
; in: LAMBDA NIL
;     (BAZ *B*)
;
; caught STYLE-WARNING:
;   undefined function: BAZ

;
; caught STYLE-WARNING:
;   This function is undefined:
;     BAZ
;
; compilation unit finished
;   caught 2 STYLE-WARNING conditions
; Evaluation aborted
CL-USER>



Thanks,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/closer-devel/attachments/20060220/2c47193b/attachment.html>

From nickb42 at gmail.com  Mon Feb 20 17:10:57 2006
From: nickb42 at gmail.com (Nick Bourner)
Date: Mon, 20 Feb 2006 17:10:57 +0000
Subject: [closer-devel] Re: Layered function troubles
In-Reply-To: <17e6dce0602200552o55f31eecy8d59ffc0716fcbb@mail.gmail.com>
References: <17e6dce0602200552o55f31eecy8d59ffc0716fcbb@mail.gmail.com>
Message-ID: <17e6dce0602200910j150a7746safd9b431d74ba58a@mail.gmail.com>

Hmm. In case anyone else has a similar problem, the blindingly stupid
mistake was sloppy programming on my part. I had assumed that
define-layered-method worked the same as defmethod, so I could get away
without using define-layered-function first because define-layered-method
would do it for me, especially since I got a warning saying that the generic
function had implicitly been created. Bad assumption. It all works fine as
long as you remember to use define-layered-function to create the generic
first.

Nick

On 2/20/06, Nick Bourner <nickb42 at gmail.com> wrote:
>
> Hi all,
>
> I'm having some troubles getting started with layered functions in
> ContextL - I keep getting undefined-function errors when I try to use a
> layered function, which I'd expect if I wasn't making the appropriate layer
> active. Transcript of a test session shown below. Can someone please tell me
> what blindingly stupid mistake I'm making?
>
> BTW I'm using sbcl 0.9.8 on OS X, but I get something similar for OpenMCL
> as well.
>
> <snip>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/closer-devel/attachments/20060220/155adb88/attachment.html>

From tjg-lisp at pentaside.org  Wed Feb 22 16:26:19 2006
From: tjg-lisp at pentaside.org (Tayssir John Gabbour)
Date: Wed, 22 Feb 2006 17:26:19 +0100
Subject: [closer-devel] Pointers on MOP tradeoffs
Message-ID: <43FC90AB.1060903@pentaside.org>

Hi,

I'm looking to learn the tradeoffs involved in the MOP spec, as well as
possible improvements (given the strength of today's hardware). Can
anyone point me to info on that, or perhaps a historical record of what
the MOP people did?

I'm already aware of papers on Paepcke's website, those on Parc's
(primarily by Kiczales), and _The Art of the MOP_ book.

I'll be happy to mention pointers on one of the lisp wikis...

Thanks for any help,
Tayssir


From pc at p-cos.net  Wed Feb 22 17:07:00 2006
From: pc at p-cos.net (Pascal Costanza)
Date: Wed, 22 Feb 2006 18:07:00 +0100
Subject: [closer-devel] Pointers on MOP tradeoffs
In-Reply-To: <43FC90AB.1060903@pentaside.org>
References: <43FC90AB.1060903@pentaside.org>
Message-ID: <21A43D63-9BA9-4F91-8B0D-99027CB1A3A2@p-cos.net>


On 22 Feb 2006, at 17:26, Tayssir John Gabbour wrote:

> Hi,
>
> I'm looking to learn the tradeoffs involved in the MOP spec, as  
> well as
> possible improvements (given the strength of today's hardware). Can
> anyone point me to info on that, or perhaps a historical record of  
> what
> the MOP people did?

You may want to take a look at Tiny CLOS and its related  
announcement. They have "improved" the slot access protocol in that  
implementation. In theory, this could lead to much improved  
efficiency for user-defined slot accesses. There is also a discussion  
of this in the book "Advances in Object-Oriented Metalevel  
Architectures and Reflection", edited by Chris Zimmermann (you should  
be able to get that one for very little money from used bookstores).  
In practice, I am not aware whether this was actually carried through  
to the end, so I remain skeptical, although I now understand the  
point better, especially after having read http://www.sbcl.org/sbcl- 
internals/Slot_002dValue.html#Slot_002dValue . (I have an idea how  
something similar to what Tiny CLOS does could be achieved in  
portable CLOS MOP code, but I haven't implemented it yet...)

Another reference point is a paper about the EuLisp MOP - see http:// 
citeseer.ist.psu.edu/bretthauer92balancing.html . One important  
"advantage" described in that paper is purportedly that EuLisp has a  
pure load-time MOP - in other words, you cannot change anything about  
classes and generic functions anymore at runtime. (Including no  
redefinition of classes, for example, which in the case of CLOS is  
already part of ANSI Common Lisp.) Dylan - which doesn't specify a  
MOP - makes similar restrictions compared to plain CLOS. What you can  
often read in those documents is that the ability to redefine things  
at runtime was typically considered a development aid, but not  
something to be used in 'real' deployed programs. For some reason,  
the belief that programs should remain static has somehow carried  
over to the Lisp world at that time. (I think the real reason is that  
a load-time MOP provides more opportunities for optimizations that  
don't need to be undone anymore, compared to a runtime MOP.)

There is a paper by Crista Lopes which describes how the step from  
run-time over load-time to compile-time MOPs has finally led to the  
notion of aspect-oriented programming. It's probably true that AOP is  
more "natural" for compile-time processing than a MOP. (Especially if  
you cannot revert to macros because your language has a too irregular  
syntax to support macros well. ;) For example, the slot access  
protocol in the CLOS MOP is a runtime protocol in the sense that the  
generic functions slot-xxx-using-class have to do their dispatch at  
runtime in the general case. The slot access protocol in Tiny CLOS is  
closer to a compile-time MOP because the slot access code can be  
completely determined once and doesn't rely on a runtime dispatch,  
but it is also somewhat harder to understand, IMHO. See http:// 
www.isr.uci.edu/tech_reports/UCI-ISR-02-5.pdf for Crista Lopes's paper.

Other interesting papers are:

- http://www.cs.indiana.edu/~jsobel/rop.html which gives a nice  
account of MOPs.
- http://people.csail.mit.edu/jrb/Projects/partial-dispatch.htm which  
describes a more modern approach of generic function dispatch than  
the one used in CLOS. With more modern I mean that that approach also  
tries to cache results at call sites which CLOS implementation don't  
seem to do, but which is now pretty common for example in JVM  
and .NET runtime implementations. With regard to the CLOS MOP this is  
"interesting" because I don't see how the specified generic function  
invocation protocols could be reconciled with such an approach.

I hope this helps...


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium






From pc at p-cos.net  Wed Feb 22 17:10:00 2006
From: pc at p-cos.net (Pascal Costanza)
Date: Wed, 22 Feb 2006 18:10:00 +0100
Subject: [closer-devel] Re: Layered function troubles
In-Reply-To: <17e6dce0602200910j150a7746safd9b431d74ba58a@mail.gmail.com>
References: <17e6dce0602200552o55f31eecy8d59ffc0716fcbb@mail.gmail.com>
	<17e6dce0602200910j150a7746safd9b431d74ba58a@mail.gmail.com>
Message-ID: <D6A556BC-013D-4591-BE0E-738C219C5FC8@p-cos.net>

Hi Nick,

Thanks for finding the mistake yourself. ;)

It would indeed be nicer if a define-layered-method could  
automatically generate a proper layered function, not an incomplete  
one as is currently accidentally the case. However, I haven't yet  
figured out how to make this work. I will try to think about a  
solution...


Pascal

On 20 Feb 2006, at 18:10, Nick Bourner wrote:

> Hmm. In case anyone else has a similar problem, the blindingly  
> stupid mistake was sloppy programming on my part. I had assumed  
> that define-layered-method worked the same as defmethod, so I could  
> get away without using define-layered-function first because define- 
> layered-method would do it for me, especially since I got a warning  
> saying that the generic function had implicitly been created. Bad  
> assumption. It all works fine as long as you remember to use define- 
> layered-function to create the generic first.
>
> Nick
>
> On 2/20/06, Nick Bourner <nickb42 at gmail.com> wrote:
> Hi all,
>
> I'm having some troubles getting started with layered functions in  
> ContextL - I keep getting undefined-function errors when I try to  
> use a layered function, which I'd expect if I wasn't making the  
> appropriate layer active. Transcript of a test session shown below.  
> Can someone please tell me what blindingly stupid mistake I'm making?
>
> BTW I'm using sbcl 0.9.8 on OS X, but I get something similar for  
> OpenMCL as well.
>
> <snip>
>
> _______________________________________________
> closer-devel mailing list
> closer-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/closer-devel/attachments/20060222/59a47b02/attachment.html>

From pc at p-cos.net  Sun Feb 26 15:07:41 2006
From: pc at p-cos.net (Pascal Costanza)
Date: Sun, 26 Feb 2006 16:07:41 +0100
Subject: [closer-devel] ContextL design question...
Message-ID: <D56FBC37-3BED-4654-9E8D-870968A71296@p-cos.net>

Hi everybody,

I am currently working on providing meta-level access to layer  
activation/deactivation in ContextL. As expected, this turns up a  
number of related questions, and one of them seems to be very  
fundamental. Before I make a solitary decision here, I would like to  
hear other people's opinions, especially from those who have already  
played around with ContextL.

Here we go: Currently, a layer is referred to only by name. So if we  
define a layer like this:

(deflayer employement)

...we activate it later on by saying that:

(with-active-layers (employment)
   ...)

In other words, layers are singletons. Until now, this doesn't matter  
much, because we cannot yet associate state with layers and cannot  
define relationships between layers. One of the goals of providing  
meta-level access to layer activation/deactivation is that we can  
start to define such relationships, like mutually exclusive layers,  
or layer dependencies, etc.

Those of you you have taken a look at the implementation of ContextL  
know that layers are internally implemented as classes. So a layer  
definition like (deflayer employment) is actually something like:

(defclass layer ()
   ()
   (:metaclass ...))

(Except for the fact that there is a provision for avoiding name  
conflicts with classes, among other things.)

Since layers are based on classes, it is actually relatively  
straightforward to allow for inheritance between layers. I have  
played around with a few toy examples, and this seems to make sense.  
Nick Bourner has sent me an example (in private) that could partially  
be modeled with such layer inheritance. Assume you have an output  
layer and different ways to perform output. This could roughly be  
modelled like this:

(deflayer output)

(deflayer html-output (output))

(deflayer xml-output (output))

(deflayer json-output (output))

So the idea is that the output layer defines the common functionality  
for generating output, while the other output layers define more  
specific functionality. Since the specific output layers inherit from  
output, common code can indeed be factored out. (The other goal is to  
ensure that at most one of the specific output layers is active at  
the same time.)

Now comes the actual design question: If we stick to the fact that  
layers are singletons, what we actually get here is a kind of  
prototype-based object model. For example, in my toy examples, I  
needed to define slots for layers which should be inherited by  
sublayers. For example:

(deflayer output ()
   ((grouped-layer-root :initform 'output
                        :reader grouped-layer-root)
    (grouped-layer-default-layer :initform 'html-output
                                 :reader grouped-layer-default-layer)))

Due to inheritance between layers, this would mean that, say,  
(grouped-layer-root (find-layer 'xml-output)) would correctly yield  
'output. In other words, we get the kind of inheritance of slots as  
with :allocation :class in standard classes.

The alternative route to go would be to leave the prototype-based  
model, but instead go for a class-based model. Then layers would  
"just" be ordinary classes. However, for layer activation/ 
deactivation, one couldn't just refere to the names anymore. Instead,  
one would have to create instances of layers, as follows:

(with-active-layers ((make-instance 'employment))
   ...)

This would allow us to have multiple instances of the same layer, and  
the inheritance model (slots & code) would be the same as in plain CLOS.

My subjective opinion is to keep the prototype-based model.  
Currently, I don't see any uses for the class-based model - i.e., I  
don't see a use for having multiple instances of the same layer. At  
the same time, the prototype-based model seems quite attractive  
because of its relative simplicity of use. In case one really needs  
multiple instances of the same layer, this could later on be achieved  
as in "real" prototype-based languages, by inheriting from existing  
prototypes and allowing for anonymous layers. But that's "just in  
case"...

So, any opinions?


Cheers,
Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium






From nickb42 at gmail.com  Mon Feb 27 18:10:35 2006
From: nickb42 at gmail.com (Nick Bourner)
Date: Mon, 27 Feb 2006 18:10:35 +0000
Subject: [closer-devel] ContextL design question...
In-Reply-To: <D56FBC37-3BED-4654-9E8D-870968A71296@p-cos.net>
References: <D56FBC37-3BED-4654-9E8D-870968A71296@p-cos.net>
Message-ID: <17e6dce0602271010p6b452b2eu2a46dc0de9b51401@mail.gmail.com>

Hi Pascal,

I have to agree with your opinion that the prototype-based approach is
the one to go for. I think that  moving to a class-based approach adds
far too much complexity for minimal or no real gain in usefulness or
expressiveness. In my opinion that would be unfortunate, because for
me one of the strengths of ContextL is that it provides a conceptually
simple, but very powerful, abstraction that  can be used to simplify
the organisation and expression of application code. Making the
abstraction more complex somewhat defeats the object - if you're not
careful you could wind up with application code that's as complex as
it would have been without the layering.

Just my 2?,

Nick

BTW - is the code for slots in layers available? I could really use
that about now :-)


On 2/26/06, Pascal Costanza <pc at p-cos.net> wrote:
> Hi everybody,
>
> I am currently working on providing meta-level access to layer
> activation/deactivation in ContextL. As expected, this turns up a
> number of related questions, and one of them seems to be very
> fundamental. Before I make a solitary decision here, I would like to
> hear other people's opinions, especially from those who have already
> played around with ContextL.
>
<snip>


From pc at p-cos.net  Tue Feb 28 08:24:59 2006
From: pc at p-cos.net (Pascal Costanza)
Date: Tue, 28 Feb 2006 09:24:59 +0100
Subject: Slots in layers, was Re: [closer-devel] ContextL design question...
In-Reply-To: <17e6dce0602271010p6b452b2eu2a46dc0de9b51401@mail.gmail.com>
References: <D56FBC37-3BED-4654-9E8D-870968A71296@p-cos.net>
	<17e6dce0602271010p6b452b2eu2a46dc0de9b51401@mail.gmail.com>
Message-ID: <E789BEC0-0BCD-45D1-BC72-5A54E9328F2D@p-cos.net>


On 27 Feb 2006, at 19:10, Nick Bourner wrote:

> Hi Pascal,
>
> I have to agree with your opinion that the prototype-based approach is
> the one to go for. I think that  moving to a class-based approach adds
> far too much complexity for minimal or no real gain in usefulness or
> expressiveness. In my opinion that would be unfortunate, because for
> me one of the strengths of ContextL is that it provides a conceptually
> simple, but very powerful, abstraction that  can be used to simplify
> the organisation and expression of application code. Making the
> abstraction more complex somewhat defeats the object - if you're not
> careful you could wind up with application code that's as complex as
> it would have been without the layering.

Thanks a lot for your feedback!

> BTW - is the code for slots in layers available? I could really use
> that about now :-)

Hmm, could you explain to me again what it is that you want here - I  
only have a rough idea from our discussion at the Dynamic Languages  
Day, but it would be helpful if you try to describe again what  
problem you actually want to solve. I hope I can then find a solution...


Cheers,
Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium






From nickb42 at gmail.com  Tue Feb 28 09:59:45 2006
From: nickb42 at gmail.com (Nick Bourner)
Date: Tue, 28 Feb 2006 09:59:45 +0000
Subject: Slots in layers,
	was Re: [closer-devel] ContextL design question...
In-Reply-To: <E789BEC0-0BCD-45D1-BC72-5A54E9328F2D@p-cos.net>
References: <D56FBC37-3BED-4654-9E8D-870968A71296@p-cos.net>
	<17e6dce0602271010p6b452b2eu2a46dc0de9b51401@mail.gmail.com>
	<E789BEC0-0BCD-45D1-BC72-5A54E9328F2D@p-cos.net>
Message-ID: <17e6dce0602280159i4d6d4b95m9812865d711706bd@mail.gmail.com>

Oops, sorry for the confusion. I was referring to the code in your
original post for defining slots in layers which were inherited by
sublayers.

I think the example was

(deflayer output ()
  ((grouped-layer-root :initform 'output .....

etc.

I still haven't completely thought through what we were talking about
at DLD, and for the most part, it may not be necessary now. But I'll
try to come up with a concrete example.

Cheers,
Nick


On 2/28/06, Pascal Costanza <pc at p-cos.net> wrote:
>
> On 27 Feb 2006, at 19:10, Nick Bourner wrote:
>
> > Hi Pascal,
> >
> > I have to agree with your opinion that the prototype-based approach is
> > the one to go for. I think that  moving to a class-based approach adds
> > far too much complexity for minimal or no real gain in usefulness or
> > expressiveness. In my opinion that would be unfortunate, because for
> > me one of the strengths of ContextL is that it provides a conceptually
> > simple, but very powerful, abstraction that  can be used to simplify
> > the organisation and expression of application code. Making the
> > abstraction more complex somewhat defeats the object - if you're not
> > careful you could wind up with application code that's as complex as
> > it would have been without the layering.
>
> Thanks a lot for your feedback!
>
> > BTW - is the code for slots in layers available? I could really use
> > that about now :-)
>
> Hmm, could you explain to me again what it is that you want here - I
> only have a rough idea from our discussion at the Dynamic Languages
> Day, but it would be helpful if you try to describe again what
> problem you actually want to solve. I hope I can then find a solution...
>
>
> Cheers,
> Pascal
>
> --
> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
> Vrije Universiteit Brussel, Programming Technology Lab
> Pleinlaan 2, B-1050 Brussel, Belgium
>
>
>
>
>


From pc at p-cos.net  Tue Feb 28 15:59:10 2006
From: pc at p-cos.net (Pascal Costanza)
Date: Tue, 28 Feb 2006 16:59:10 +0100
Subject: Slots in layers,
	was Re: [closer-devel] ContextL design question...
In-Reply-To: <17e6dce0602280159i4d6d4b95m9812865d711706bd@mail.gmail.com>
References: <D56FBC37-3BED-4654-9E8D-870968A71296@p-cos.net>
	<17e6dce0602271010p6b452b2eu2a46dc0de9b51401@mail.gmail.com>
	<E789BEC0-0BCD-45D1-BC72-5A54E9328F2D@p-cos.net>
	<17e6dce0602280159i4d6d4b95m9812865d711706bd@mail.gmail.com>
Message-ID: <2C30E3AD-F004-4C85-BF25-4E7FFBBBD468@p-cos.net>


On 28 Feb 2006, at 10:59, Nick Bourner wrote:

> Oops, sorry for the confusion. I was referring to the code in your
> original post for defining slots in layers which were inherited by
> sublayers.
>
> I think the example was
>
> (deflayer output ()
>   ((grouped-layer-root :initform 'output .....
>
> etc.

Ah, ok. You can already do this by using undocumented behavior. So  
for examlpe, it should be possible to say this:

(deflayer some-layer ()
   ((some-slot :initform 42 :allocation :class :reader some-slot)))

...and then access the slot like this:

(some-slot (layer-prototype (find-layer 'some-layer)))

[Untested!]

My goal is to make this look less ugly, but the semantics will be  
more or less the same. (This is all a side effect of the fact that  
layers are internally implemented as classes.)

> I still haven't completely thought through what we were talking about
> at DLD, and for the most part, it may not be necessary now. But I'll
> try to come up with a concrete example.

OK, would be nice. (But don't worry too much...)


Cheers,
Pascal

>
> Cheers,
> Nick
>
>
> On 2/28/06, Pascal Costanza <pc at p-cos.net> wrote:
>>
>> On 27 Feb 2006, at 19:10, Nick Bourner wrote:
>>
>>> Hi Pascal,
>>>
>>> I have to agree with your opinion that the prototype-based  
>>> approach is
>>> the one to go for. I think that  moving to a class-based approach  
>>> adds
>>> far too much complexity for minimal or no real gain in usefulness or
>>> expressiveness. In my opinion that would be unfortunate, because for
>>> me one of the strengths of ContextL is that it provides a  
>>> conceptually
>>> simple, but very powerful, abstraction that  can be used to simplify
>>> the organisation and expression of application code. Making the
>>> abstraction more complex somewhat defeats the object - if you're not
>>> careful you could wind up with application code that's as complex as
>>> it would have been without the layering.
>>
>> Thanks a lot for your feedback!
>>
>>> BTW - is the code for slots in layers available? I could really use
>>> that about now :-)
>>
>> Hmm, could you explain to me again what it is that you want here - I
>> only have a rough idea from our discussion at the Dynamic Languages
>> Day, but it would be helpful if you try to describe again what
>> problem you actually want to solve. I hope I can then find a  
>> solution...
>>
>>
>> Cheers,
>> Pascal
>>
>> --
>> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
>> Vrije Universiteit Brussel, Programming Technology Lab
>> Pleinlaan 2, B-1050 Brussel, Belgium
>>
>>
>>
>>
>>
>

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium






From pc at p-cos.net  Tue Feb 28 21:06:01 2006
From: pc at p-cos.net (Pascal Costanza)
Date: Tue, 28 Feb 2006 22:06:01 +0100
Subject: Slots in layers,
	was Re: [closer-devel] ContextL design question...
In-Reply-To: <17e6dce0602281148s64f78c98mc59eecb58318b2db@mail.gmail.com>
References: <D56FBC37-3BED-4654-9E8D-870968A71296@p-cos.net>
	<17e6dce0602271010p6b452b2eu2a46dc0de9b51401@mail.gmail.com>
	<E789BEC0-0BCD-45D1-BC72-5A54E9328F2D@p-cos.net>
	<17e6dce0602280159i4d6d4b95m9812865d711706bd@mail.gmail.com>
	<2C30E3AD-F004-4C85-BF25-4E7FFBBBD468@p-cos.net>
	<17e6dce0602281148s64f78c98mc59eecb58318b2db@mail.gmail.com>
Message-ID: <985E7823-5C7A-4B0E-87AD-94BF4973B333@p-cos.net>


On 28 Feb 2006, at 20:48, Nick Bourner wrote:

> Thanks for that, I'll give it a try.
>
> Is the value of the slot global or can it be set on a per-thread basis
> like active layers? I was thinking that it could be a good way of
> carrying information for a particular activation of a layer. Say, for
> instance, a stream for a display layer to write to or something. Then
> you could have something like
>
> (with-active-layers ((some-layer :some-slot a-value) some-other-layer)
>    ...)
> or
> (ensure-active-layer (some-layer :some-slot a-value))
>
> rather than something like
>
> (let ((*some-special* a-value))
>   (with-active-layers (some-layer some-other-layer)
>     ....
>
> Not a whole lot different but I think it just expresses the intent
> slightly more clearly.

Now, that's a very neat idea, especially the syntax. And I think it  
should be possible to implement this in a relatively straightforward  
way.

> My guess is that because it's using an allocation of :class it's
> global - one value for all threads.

Currently, it is indeed the case that such a slot cannot be  
dynamically scoped. I will turn it into a potentially special slot,  
like in the special-classes. This will probably take a little time,  
so I hope you can live with the workarounds for the moment...

Thanks again,
Pascal

>
> Cheers,
> Nick
>
> On 2/28/06, Pascal Costanza <pc at p-cos.net> wrote:
>>
>
> <snip>
>
>> Ah, ok. You can already do this by using undocumented behavior. So
>> for examlpe, it should be possible to say this:
>>
>> (deflayer some-layer ()
>>    ((some-slot :initform 42 :allocation :class :reader some-slot)))
>>
>> ...and then access the slot like this:
>>
>> (some-slot (layer-prototype (find-layer 'some-layer)))
>>
>> [Untested!]
>>
>> My goal is to make this look less ugly, but the semantics will be
>> more or less the same. (This is all a side effect of the fact that
>> layers are internally implemented as classes.)
>>
>>> I still haven't completely thought through what we were talking  
>>> about
>>> at DLD, and for the most part, it may not be necessary now. But I'll
>>> try to come up with a concrete example.
>>
>> OK, would be nice. (But don't worry too much...)
>>
>>
>> Cheers,
>> Pascal
>>
>>>
>>> Cheers,
>>> Nick
>>>
>>>
>>> On 2/28/06, Pascal Costanza <pc at p-cos.net> wrote:
>>>>
>>>> On 27 Feb 2006, at 19:10, Nick Bourner wrote:
>>>>
>>>>> Hi Pascal,
>>>>>
>>>>> I have to agree with your opinion that the prototype-based
>>>>> approach is
>>>>> the one to go for. I think that  moving to a class-based approach
>>>>> adds
>>>>> far too much complexity for minimal or no real gain in  
>>>>> usefulness or
>>>>> expressiveness. In my opinion that would be unfortunate,  
>>>>> because for
>>>>> me one of the strengths of ContextL is that it provides a
>>>>> conceptually
>>>>> simple, but very powerful, abstraction that  can be used to  
>>>>> simplify
>>>>> the organisation and expression of application code. Making the
>>>>> abstraction more complex somewhat defeats the object - if  
>>>>> you're not
>>>>> careful you could wind up with application code that's as  
>>>>> complex as
>>>>> it would have been without the layering.
>>>>
>>>> Thanks a lot for your feedback!
>>>>
>>>>> BTW - is the code for slots in layers available? I could really  
>>>>> use
>>>>> that about now :-)
>>>>
>>>> Hmm, could you explain to me again what it is that you want here  
>>>> - I
>>>> only have a rough idea from our discussion at the Dynamic Languages
>>>> Day, but it would be helpful if you try to describe again what
>>>> problem you actually want to solve. I hope I can then find a
>>>> solution...
>>>>
>>>>
>>>> Cheers,
>>>> Pascal
>>>>
>>>> --
>>>> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
>>>> Vrije Universiteit Brussel, Programming Technology Lab
>>>> Pleinlaan 2, B-1050 Brussel, Belgium
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
>> Vrije Universiteit Brussel, Programming Technology Lab
>> Pleinlaan 2, B-1050 Brussel, Belgium
>>
>>
>>
>>
>>
>

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium






From nickb42 at gmail.com  Tue Feb 28 19:48:35 2006
From: nickb42 at gmail.com (Nick Bourner)
Date: Tue, 28 Feb 2006 19:48:35 +0000
Subject: Slots in layers,
	was Re: [closer-devel] ContextL design question...
In-Reply-To: <2C30E3AD-F004-4C85-BF25-4E7FFBBBD468@p-cos.net>
References: <D56FBC37-3BED-4654-9E8D-870968A71296@p-cos.net>
	<17e6dce0602271010p6b452b2eu2a46dc0de9b51401@mail.gmail.com>
	<E789BEC0-0BCD-45D1-BC72-5A54E9328F2D@p-cos.net>
	<17e6dce0602280159i4d6d4b95m9812865d711706bd@mail.gmail.com>
	<2C30E3AD-F004-4C85-BF25-4E7FFBBBD468@p-cos.net>
Message-ID: <17e6dce0602281148s64f78c98mc59eecb58318b2db@mail.gmail.com>

Thanks for that, I'll give it a try.

Is the value of the slot global or can it be set on a per-thread basis
like active layers? I was thinking that it could be a good way of
carrying information for a particular activation of a layer. Say, for
instance, a stream for a display layer to write to or something. Then
you could have something like

(with-active-layers ((some-layer :some-slot a-value) some-other-layer)
   ...)
or
(ensure-active-layer (some-layer :some-slot a-value))

rather than something like

(let ((*some-special* a-value))
  (with-active-layers (some-layer some-other-layer)
    ....

Not a whole lot different but I think it just expresses the intent
slightly more clearly.

My guess is that because it's using an allocation of :class it's
global - one value for all threads.

Cheers,
Nick

On 2/28/06, Pascal Costanza <pc at p-cos.net> wrote:
>

<snip>

> Ah, ok. You can already do this by using undocumented behavior. So
> for examlpe, it should be possible to say this:
>
> (deflayer some-layer ()
>    ((some-slot :initform 42 :allocation :class :reader some-slot)))
>
> ...and then access the slot like this:
>
> (some-slot (layer-prototype (find-layer 'some-layer)))
>
> [Untested!]
>
> My goal is to make this look less ugly, but the semantics will be
> more or less the same. (This is all a side effect of the fact that
> layers are internally implemented as classes.)
>
> > I still haven't completely thought through what we were talking about
> > at DLD, and for the most part, it may not be necessary now. But I'll
> > try to come up with a concrete example.
>
> OK, would be nice. (But don't worry too much...)
>
>
> Cheers,
> Pascal
>
> >
> > Cheers,
> > Nick
> >
> >
> > On 2/28/06, Pascal Costanza <pc at p-cos.net> wrote:
> >>
> >> On 27 Feb 2006, at 19:10, Nick Bourner wrote:
> >>
> >>> Hi Pascal,
> >>>
> >>> I have to agree with your opinion that the prototype-based
> >>> approach is
> >>> the one to go for. I think that  moving to a class-based approach
> >>> adds
> >>> far too much complexity for minimal or no real gain in usefulness or
> >>> expressiveness. In my opinion that would be unfortunate, because for
> >>> me one of the strengths of ContextL is that it provides a
> >>> conceptually
> >>> simple, but very powerful, abstraction that  can be used to simplify
> >>> the organisation and expression of application code. Making the
> >>> abstraction more complex somewhat defeats the object - if you're not
> >>> careful you could wind up with application code that's as complex as
> >>> it would have been without the layering.
> >>
> >> Thanks a lot for your feedback!
> >>
> >>> BTW - is the code for slots in layers available? I could really use
> >>> that about now :-)
> >>
> >> Hmm, could you explain to me again what it is that you want here - I
> >> only have a rough idea from our discussion at the Dynamic Languages
> >> Day, but it would be helpful if you try to describe again what
> >> problem you actually want to solve. I hope I can then find a
> >> solution...
> >>
> >>
> >> Cheers,
> >> Pascal
> >>
> >> --
> >> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
> >> Vrije Universiteit Brussel, Programming Technology Lab
> >> Pleinlaan 2, B-1050 Brussel, Belgium
> >>
> >>
> >>
> >>
> >>
> >
>
> --
> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
> Vrije Universiteit Brussel, Programming Technology Lab
> Pleinlaan 2, B-1050 Brussel, Belgium
>
>
>
>
>