headers
Pascal Costanza | 2 Mar 2006 17:07

Re: Slots in layers, was Re: ContextL design question...

Hi Nick and everyone else,

On 28 Feb 2006, at 22:06, Pascal Costanza wrote:

> 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.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Drew Crampsie | 3 Mar 2006 03:42

Re: Slots in layers, was Re: ContextL design question...

Pascal Costanza wrote:

>
> I haven't extended the with-active-layers construct, though. Here are  
> the reasons:
> - It would really only look neat when used with initargs instead of  
> accessors. However, the mapping of initargs to actual slots can be  
> changed at runtime in CLOS, so I would have to emit code with quite  
> some overhead here that would determine the current mapping of an  
> initarg to its actual slot. Worse, an initarg could actually be  
> mapped to more than one slot, which would complicate the code even  
> further, with very little reward. I wanted to avoid that.

Sounds like my WITH-SPECIAL-INITARGS construct, which has all the 
drawbacks you mentioned, but simplifies the implementation of 
Lisp-on-Lines significantly.

it's used like this like this :

(with-special-initargs (object :some-initarg value :some-other-initarg 
another-value)
  ...)

Below is the implementation. Use it however you want :)

(defmethod initargs.slot-names (object)
  "Returns ALIST of (initargs) . slot-name."
  (nreverse (mapcar #'(lambda (slot)
          (cons (closer-mop:slot-definition-initargs slot)
            (closer-mop:slot-definition-name slot)))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pascal Costanza | 3 Mar 2006 17:30

Re: Slots in layers, was Re: ContextL design question...


On 3 Mar 2006, at 03:42, Drew Crampsie wrote:

> Pascal Costanza wrote:
>
>> I haven't extended the with-active-layers construct, though. Here  
>> are  the reasons:
>> - It would really only look neat when used with initargs instead  
>> of  accessors. However, the mapping of initargs to actual slots  
>> can be  changed at runtime in CLOS, so I would have to emit code  
>> with quite  some overhead here that would determine the current  
>> mapping of an  initarg to its actual slot. Worse, an initarg could  
>> actually be  mapped to more than one slot, which would complicate  
>> the code even  further, with very little reward. I wanted to avoid  
>> that.
>
> Sounds like my WITH-SPECIAL-INITARGS construct, which has all the  
> drawbacks you mentioned, but simplifies the implementation of Lisp- 
> on-Lines significantly.

OK, I will try to integrate this somehow. In order to make this work,  
I have started to add the opportunity to declare :initarg options for  
slots in deflayer forms. However, this has revealed a few bugs with  
regard to special slots with :allocation :class.

I have fixed those bugs and submitted the changes to the darcs  
repository. Here are some important remarks:

- :initarg options are now indeed supported in deflayer forms.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pascal Costanza | 5 Mar 2006 13:42

with-special-initargs, etc.

Hi,

OK, there is a new version of ContextL in the darcs repository with  
the following extensions:

- with-special-initargs allows you to rebind slots in objects via  
initargs. The syntax looks as follows:

(with-special-initargs ((object1 :initarg1 value1 :initarg2 value2)
                         (object2 :initarg3 value3 :initarg4 value4))
   ... body ...)

All the objects, initargs and values are in evaluated positions.  
Initialization goes through shared-initialize so that you can do  
further customizations.

There is also a with-special-initargs*:

(with-special-initargs* ((object1 ...)
                          (object2 ...))
   ... body ...)

The difference is that in with-special-initargs, the objects,  
initargs and values are evaluated before any rebinding is performed,  
while in with-special-initargs*, first object1 is reinitialized with  
dynamic scoped, then object2, and so forth.

- with-active-layers is extended accordingly. If you only specify  
layer names, then it works as before:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pascal Costanza | 5 Mar 2006 15:24

Re: Re: Layered function troubles


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.

I have tried to make it work that you don't need so say (define- 
layered-function ...), but unfortunately, the CLOS MOP does not allow  
me to express this - at least, it's not obvious to me how to do that.  
(There are some subtleties wrt the :argument-precedence-order  
argument to ensure-generic-function that are not that nice to deal  
with...)

Sorry...

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
Permalink | Reply | 1 comment |
headers
Nick Bourner | 5 Mar 2006 20:56
Picon

Re: Re: Layered function troubles

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

<snip>

> I have tried to make it work that you don't need so say (define-
> layered-function ...), but unfortunately, the CLOS MOP does not allow
> me to express this - at least, it's not obvious to me how to do that.
> (There are some subtleties wrt the :argument-precedence-order
> argument to ensure-generic-function that are not that nice to deal
> with...)
>
> Sorry...
>

No worries, it wasn't a big problem. I just thought it would be useful
to note it somewhere visible in case anyone else hit the same problem.

Nick
Permalink | Reply | 0 comments |
headers
Nick Bourner | 5 Mar 2006 21:16
Picon

Slot definition inheritance

Hi all,

Not sure this is entirely on topic here, but it's a MOP question and
I'm using closer-mop :-)

Does anyone know how (or indeed if it is possible) to have a slot
inherit from two different slot definitions, so that the effective
slot definition is the union of the two direct slot definitions.
There's code in section 3.5.2 of AMOP that seems like it would be
possible by making an effective slot definition on the fly using
"make-effective-slot-definition" but that doesn't seem to exist in
SBCL or OpenMCL, or at least it isn't exported from wherever it's
hiding.

I have a suspicion I'm going to have to do this by making one slot
definition a subclass of the other, but something like the AMOP stuff
would sure be handy.

Anyone know for sure?

Thanks,
Nick
Permalink | Reply | 2 comments |
headers
Pascal Costanza | 7 Mar 2006 17:22

Re: Slot definition inheritance


On 5 Mar 2006, at 21:16, Nick Bourner wrote:

> Hi all,
>
> Not sure this is entirely on topic here, but it's a MOP question and
> I'm using closer-mop :-)
>
> Does anyone know how (or indeed if it is possible) to have a slot
> inherit from two different slot definitions, so that the effective
> slot definition is the union of the two direct slot definitions.
> There's code in section 3.5.2 of AMOP that seems like it would be
> possible by making an effective slot definition on the fly using
> "make-effective-slot-definition" but that doesn't seem to exist in
> SBCL or OpenMCL, or at least it isn't exported from wherever it's
> hiding.
>
> I have a suspicion I'm going to have to do this by making one slot
> definition a subclass of the other, but something like the AMOP stuff
> would sure be handy.
>
> Anyone know for sure?

Yes - that function doesn't exist.

The AMOP book uses different variations of a metaobject protocol  
throughout the book to make certain points clear. The only  
specification that's actually somewhat binding for CLOS are chapters  
5 and 6. There's no "make-effective-slot-definition" mentioned there.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gary King | 7 Mar 2006 17:49
Favicon
Gravatar

Re: Slot definition inheritance

FWIW, there is a not perfect implementation of this sort of thing in  
the metabang-dynamic-classes ASDF system (which is really part of  
metatilities. It includes simple-define-class and define-class. Both  
of these just create classes and don't worry about caching. It also  
includes a system to map initargs to mixins which can be used to  
build classes as necessary. These are cached. As an example, here is  
some code from CL-Containers. First, I tell dynamic-classes which  
subclasses are necessary for various initargs:

(add-parameter-≥dynamic-class :iterator :transform 'transforming- 
iterator-mixin)
(add-parameter-≥dynamic-class :iterator :filter 'filtered-iterator- 
mixin)
(add-parameter-≥dynamic-class :iterator :unique 'unique-value- 
iterator-mixin)
(add-parameter-≥dynamic-class :iterator :circular 'circular-iterator- 
mixin)

Now when I make an iterator, I get a different class depending on  
what I ask for...

(class-of (make-iterator '(1 2 3 2 4 5) :filter #'oddp))
==> #<STANDARD-CLASS FILTERED-ITERATOR-MIXIN-AND-LIST-ITERATOR>

(make-iterator '(3 2 4 1 3 2) :filter #'oddp :unique t)
==> #<STANDARD-CLASS FILTERED-ITERATOR-MIXIN-AND-UNIQUE-VALUE- 
ITERATOR-MIXIN-AND-LIST-ITERATOR>

I don't have a great sense of what the cost of this machinery is  
(though it is small enough that I use it quite a bit without feeling
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pascal Costanza | 10 Mar 2006 17:25

Metacircular layer activation

Hi,

I have finally added a metaobject protocol to ContextL. The changes  
are as follows:

- A layer is an instance of a ContextL-specific metaclass. By  
default, it is the metaclass standard-layer-class. You can derive  
your own metaclasses from that class and declare a layer definition  
to be an instance of your new metaclass. For example:

(deflayer some-layer (... some super layers ...)
   (... some slots ...)
   (:layer-class my-layer-class))

- There are two layered functions activate-layer-using-class and  
deactivate-layer-using-class. You can specialize them and/or put them  
in your own layers. All layer activations/deactivations go through  
those layered functions. For example:

(define-layered-method activate-layer-using-class :in-layer some-layer
    ((layer my-layer-class) active-layers)
    ...)

These layered functions return two values: A new list of active  
layers and a boolean flag indicating whether the result can be cached  
or not. If the second return value is true, activate-layer-using- 
class won't be called anymore for the same list of active layers, but  
the previously computed value will be reused. The same holds for  
deactivate-layer-using-class.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane