[closer-devel] define-layered-method syntax

[Pascal Costanza]

On 20 Jul 2007, at 02:00, Attila Lendvai wrote:

>> Common Lisp already has a notion of function names as lists, in the
>> form of '(setf function-name). So that case would have to be covered
>> as well.
>
> oh, heh, to be honest i didn't think of that...
>
>> Of course, your suggestion would have the advantage that it saves
>> some space. I have already been hit by this a couple of times, trying
>> to fit examples of layered methods in papers. ;) In your experience,
>> how much better is your proposed syntax?
>
> well, in situations like this "better" is a question of taste... :) i
> like the proposed syntax more for its compactness and somehow my
> paren-matcher (brain) can also pick up the layer name better this way.
> it didn't cause me any headaches yet, but i have to admit, that i've
> never wanted to work with layered setf methods... but handling them
> should be doable. for example:
>
> (d-l-m ((setf foo) some-layer) (new-value arg1) ...)

That's still an easy case. I am more concerned about this:

(d-l-m (setf foo) (...) ...)

Is this a method for '(setf foo) in the layer 't, or is this a method  
for 'setf in the layer 'foo?

Of course, per ANSI Common Lisp we are not allowed to define a  
function 'setf. But what if some library or some CL implementation  
comes up with additional extended function names, like:

(d-l-m (letf foo) (...) ...)

So in order to avoid clashes of naming conventions, I would have to  
require that layers are always specified, even when they are just 't.  
I'd find that more awkward than having to say :in-layer some-layer.

> but either case, i think we should avoid playing dirty tricks with
> things like (setf foo some-layer)
>
> the background is that recently i had to reach under my d-l-m wrappers
> and define a layered method on a combination of a backend and a form,
> which my wrapper macros didn't support. and i got used to them so much
> that the "barebone" d-l-m with its :in-layer just felt strange.
> therefore this proposal/question was born.

I also sometimes get confused myself and forget where :in-layer has  
to be placed (especially in define-layered-class). But I couldn't  
come up with something better yet, given the issues some of which I  
have sketched above. As a small workaround for the wordiness of the  
keyword, I could accept :in as an alternative for :in-layer. Would  
that help at least a little?

Please also keep in mind that define-layered-method already provides  
an extension for accessing the current layer:

(d-l-m foo :in-layer (l some-layer) (...) ...)

This binds the current layer to the local variable l. This is, for  
example, useful when using call-next-method and you want to change  
some of the parameters.


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