From pc at p-cos.net Thu Oct 2 13:49:37 2008 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 2 Oct 2008 15:49:37 +0200 Subject: [closer-devel] Contextl patch: make ensure-layered-method work with function objects as well as names. In-Reply-To: References: Message-ID: Hi, OK, I have added a slightly modified version to the repository. Thanks a lot again for this patch. Best, Pascal On 27 Sep 2008, at 23:05, Drew Crampsie wrote: > Hello, > > In lol i use ensure-layered-method directly on generic functions. I've > been using this modified version of ensure-layered-method and thought > i'd try and sneak it in :). > > (defun ensure-layered-method > (layered-function-designator > lambda-expression > &key > (layered-function > (if (functionp layered-function-designator) > layered-function-designator > (fdefinition (lf-definer-name layered-function-designator)))) > #-(or allegro clisp cmu ecl mcl openmcl) > (method-class > (generic-function-method-class > layered-function)) > (in-layer 't) > (qualifiers ()) > (lambda-list (cadr lambda-expression)) > (specializers (required-args lambda-list (constantly (find- > class 't))))) > (let ((layer-arg (gensym "LAYER-ARG-"))) > (destructuring-bind > (lambda (&rest args) &body body) > lambda-expression > (unless (eq lambda 'lambda) > (error "Incorrect lambda expression: ~S." lambda-expression)) > (ensure-method layered-function > `(lambda (,layer-arg , at args) , at body) > #-(or allegro clisp cmu ecl mcl openmcl) :method- > class > #-(or allegro clisp cmu ecl mcl openmcl) method- > class > :qualifiers qualifiers > :lambda-list `(,layer-arg , at lambda-list) > :specializers (cons (find-layer-class in-layer) > specializers))))) > > Cheers, > > drewc > _______________________________________________ > 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 From pc at p-cos.net Thu Oct 2 13:57:30 2008 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 2 Oct 2008 15:57:30 +0200 Subject: [closer-devel] slots on layers In-Reply-To: References: <6777FEE5-5846-4B94-9772-9865F03F21BF@p-cos.net> <45F07A27-8392-4DD8-9689-A5A6FD21E3B4@p-cos.net> Message-ID: <817A5E13-CEDD-417B-8624-26650A3A127C@p-cos.net> Just to give a note that I haven't forgotten about this: I have a response for this email, but need a bit more time in a row to formulate it well. Sorry for the delay, I hope to be able to post the reply soon. I expect to be able to implement what's necessary by end of October / beginning of November. I now have a pretty good idea what to do that should be useful for everyone, but I hope to be able to discuss this before making the changes to (hopefully) get your acknowledgment. Best, Pascal On 15 Sep 2008, at 22:35, Attila Lendvai wrote: >> 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). > > > my concerns are mostly related to debugging a random problem with this > machinery operating in the background. also i think that it's a middle > ground solution that on one hand has lost its simplicity and on the > other hand doesn't give a generic solution, either (see below)... > > >> 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: > > > it's available at: > http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-dwim-wui;a=summary > > search for call-in-component-environment and > with-restored-component-environment. > > starting the thing is more pain than it should be for now, especially > when you want to use the interesting part (the metagui that can > present a random cl-perec ER model). > > >> + 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? > > > it's basically a generic method called for each component in the > component path to the root, in a definite order. so you can bind > whatever you want in :around methods... > > of course it means that it's more trouble to rebind variables with > this infrastructure than it would be with a dedicated dynamic > environment support. but on the other hand we can run code if needed, > as opposed to simply reinstating special bindings. and also it's a > specialized infrastructure related to components/gui's, nothing > generally usable. > > btw, i think the generic solution to this problem would be to have > continuations (either delimited or not) with dynamic-wind support > (e.g. as in scheme). for me anything else feels as a specific solution > given to a certain use-case. in fact if i really needed this generic > language feature, then i would implement closure based CPS in > cl-delico (it only has an interpreter for now) and add dynamic-wind > support to it. > > so, to sum up my current state of mind: i'd implement layer instance > modification using a specialized cloning (random sideffect: much > faster slot access on layers); do our specialized one-shot > continuations using some light macrology (as currently done); and if i > ever wanted to have all this in a generic way, then i'd extend > cl-delico with dynamic-wind. > > but i'm right before falling asleep, so... :) > > -- > attila -- 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 Fri Oct 3 14:24:16 2008 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 3 Oct 2008 16:24:16 +0200 Subject: [closer-devel] slots on layers In-Reply-To: References: <6777FEE5-5846-4B94-9772-9865F03F21BF@p-cos.net> <45F07A27-8392-4DD8-9689-A5A6FD21E3B4@p-cos.net> Message-ID: <7184E9A9-A317-44A0-80B2-BDF51B9C709D@p-cos.net> Hi, Back to this topic... ;) I wanted to write a response where I comment on the fact that I find dynamic-wind quite questionable - primarily because the dynamic environments established with dynamic-wind are not first-class. Dynamic-wind is actually also a controversial feature in the Scheme community - it can be shown that call/cc with dynamic-wind can be implemented in terms of call/cc without dynamic-wind, but not the other way around, so in a 'minimal' language, dynamic-wind is actually not necessary. But after spending some more thought on this, I think I can propose a solution that should make everybody happy. Assume we have a function current-dynamic-environment and a macro with- dynamic-environment with which you can get and set the current dynamic environment. The idea is that specifically registered special variables can be captured in such dynamic environments. For example, all special slots in special classes, and the current layer context will be such registered special variables. On top of that, it will be possible to switch off support for dynamic environments completely for people who really don't like them. (There will be a restriction wrt side effects - assignments to such special variables will probably not be recorded correctly in all situations. But that shouldn't be a too strong restriction, because you typically rebind such variables rather than set them. I will provide a detailed description when assignments work and when they don't.) Now, if you have support for call/cc in some other library, you can add support for ContextL dynamic enviroments like this: (defun dcall/cc (continuation) (let ((dynamic-environment (current-dynamic-environment))) (call/cc (lambda (k) (funcall continuation (lambda (value) (with-dynamic-environment dynamic-environment (funcall k value)))))))) It should also be possible to integrate support for both ContextL dynamic environments and dynamic-wind into one construct, if necessary. Next, there should be a way to support partial continuations. My current idea is to have something like a function mark-dynamic- environment that marks a portion of the current dynamic environment, and that current-dynamic-environment can refer to such marks. So for example, something like this: (let ((mark (mark-current-dynamic-environment))) ... ... (current-dynamic-environment mark) ... ...) The idea is that current-dynamic-environment captures the current environment up until the specified mark (and if no mark is given, the whole dynamic environment is captured). There should then also be a form of with-dynamic-environment with reestablishes such a partial dynamic environment - don't know exactly how to do that yet. Partial dynamic environments should make it easier to work correctly with partial continuations, and since that's what you typically get for Common Lisp, I think that's quite important. So, do you think that the sketched solution covers the major concerns? 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