[closer-devel] slots on layers

[Pascal Costanza]

Hi again,

This is a useful discussion, because it's about something that I  
wanted to integrate into ContextL for some item anyway, and we can now  
make some "right" decisions here.

On 31 Aug 2008, at 00:44, Attila Lendvai wrote:

>> What you describe seems to be a classic scenario for using first- 
>> class
>> continuations. What I already have on my todo list for ContextL is  
>> support
>
> to be more precise what we need is only one-shot continuations, which
> can simply be done with a lambda plus some macrology without much
> overhead.

OK, that sounds good. (Although I would like to make it work with more  
full-fledged continuations as well.)

>> for first-class dynamic closures. The idea would be that you can say
>> something like (capture-dynamic-bindings), which gives you a first- 
>> class
>> representation of all special variables, which you can later  
>> reinstate by
>> something like (with-reinstated-dynamic-bindings ...). Such a dynamic
>> closure facility would capture the current representation of active  
>> layers
>> (because that's in a special variable), as well as, for example,  
>> special
>> slots both in the layers and in other objects.
>>
>> (It won't be as general as that, I will have to require registering  
>> the
>> special variables that you want to see captured, but I think I can  
>> make this
>> relatively non-intrusive.)
>>
>> Would that solve your problem?
>
> i think it would, but i still don't see why it is worth it. what you
> describe seems to be a lot more complex than if we cloned a new
> instance at each change to the layer context. AFAICS, from the user's
> POV the two solutions would be equivalent (except the different
> performance characteristics), but the implementation of the
> make-instance/copy-slots seems much more simple with potentially less
> surprises.

True, that implementation seems more simple (although I think my  
suggestion is not that complicated either, but I'm probably not  
communicating it well enough at the moment).

I tend towards the first-class dynamic environments because it sounds  
to me to be the "right" solution, whereas what you suggest seems very  
specific to some (important) detail ContextL. My hope is that the  
dynamic environments could be generalized in such a way that they  
become useful outside of ContextL as well. They will probably be part  
of the ContextL library, but it should be possible to use them without  
using any of ContextL's other features. (It is my strong belief that  
language constructs should be as independent of each other as possible.)

> as of the performance, these layer prototype instances would have
> standard slots that are much faster to access, while layer activation
> would be slower, but that's rare (at least in our use-cases). in fact
> the entire contextl related performance impact on our application is
> probably negligible, and probably most of it comes from the extra
> dispatch parameter.

I'm actually not so worried about performance either, it's just a nice  
side effect if you can get good performance, but it's not on the top  
of my priority list.

> i don't want to say that first class dynamic closures are not useful
> in general, but in this situation it feels like too much machinery.

I think I can make it work in such a way that it will feel very  
seamless. My idea is that the current context parameter and any  
special slots defined in layered and special classes will be  
automatically captured by default, without you having to worry about  
anything. I'm very certain that this should work (as always, it could  
have nasty corner cases that I don't know about yet, of course).

> we already have a more fine-grained protocol to restore the dynamic
> environment when for example a partial ajax rendering happens
> somewhere inside the component hierarchy (components can specialize
> the call-in-component-environment method, which is called on the
> parent path of the component, one by one). most, but not all of its
> usage is restoring dynamic variable bindings that could be covered by
> capture-dynamic-bindings, but the protocol is more flexible than that.
> it costs us a dozen of extra method calls, but our main priority is
> code maintainability/flexibility/reuse, not speed.

I am very interested to hear more about this, because this seems to be  
a part where I can double check whether "my" dynamic environments are  
general enough to support such things:

+ To what extent is your machinery more fine-grained? Can you select  
which special variables are captured and which aren't? Or do you mean  
something else here?

+ Do you have some source code publicly available where this is  
provided and used? I would like to take a look at it, if you are fine  
with that.

> i'm sorry if i sounded negative, but i don't have a fine enough
> english for this. and i'm just a user anyway, so take it all with a
> piece of salt... :) i may even not see the whole picture or an
> important detail.

Don't worry, I also don't have a complete view of the whole picture,  
that's why it's good to have this discussion.


Best,
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