From attila.lendvai at gmail.com Sun Oct 1 19:20:33 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 1 Oct 2006 21:20:33 +0200 Subject: [metacopy-devel] several paralell copy protocols Message-ID: hi! there's no one-fits-all solution for copying objects (or equality check, or hash key calculation (although this last one is the least varying)). we need to copy queries (lisp forms) that may contain embedded persistent objects, and at the same time we also need to copy standalone persistent objects. but the semantics need to be different in the two situation. so we basically need two paralell generic function protocols, like 'copy-query and 'copy-persistent-object (as opposed to the single 'copy-thing). then it would be cool if these copy method groups could specialize each other, but it's not that important. like you have a copy-animal protocol and then a copy-dog protocol that overrides only those part of the copy-animal that needs to be specialized. i can only think of two impl srategies currently: - using macros and actually generating the generic methods - add an implicit parameter to the copy methods that you can dispatch on. this solution would be actually a naiive implementation of contextl, so maybe some form of contextl integration were also enough. i wonder what people think about this problem and the possible solutions... -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gwking at metabang.com Thu Oct 5 12:33:46 2006 From: gwking at metabang.com (Gary King) Date: Thu, 5 Oct 2006 08:33:46 -0400 Subject: [metacopy-devel] several paralell copy protocols In-Reply-To: References: Message-ID: Hi Attila, > we need to copy queries (lisp forms) that may contain embedded > persistent objects, and at the same time we also need to copy > standalone persistent objects. but the semantics need to be > different in the two situation. I agree that there is no one-size-fits-all (OSFA) solution but I don't understand why you need different protocols in the case you mention. If PO is a persistent-object, then why do (copy-thing PO) and (copy-thing (list 1 2 3 PO)) need to treat PO differently? thanks, -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Thu Oct 5 13:20:22 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 5 Oct 2006 15:20:22 +0200 Subject: [metacopy-devel] several paralell copy protocols In-Reply-To: References: Message-ID: > > I agree that there is no one-size-fits-all (OSFA) solution but I don't > understand why you need different protocols in the case you mention. If PO > is a persistent-object, then why do > > (copy-thing PO) > > and > > (copy-thing (list 1 2 3 PO)) > > need to treat PO differently? > these are the two use-cases: 1. user wants to clone an object. we have annotations on the model how to clone different properties (like specific associations) of PO's. 2. user wants to manipulate queries, which involves saving and copying queries. queries may contain direct (lisp vm level) references to PO's. or to be more precise references to entities which are PO's with identity. the contract of entities is that in a given transaction there may only be one clos object associated to the transaction that describes a given entity. therefore when copying a query we must not copy the PO, only "copy" by reference. so it is basically: (clone-persistent-object PO) and (copy-query `(select (foo) (assert (typep foo 'some-entity)) (assert (parent-of foo) PO))) now one may argue that 1 should not use copy-thing, but the standard behaviour is ok in most of the time and because of that there won't be too many model annotations. so not using copy-thing would mean quite some code duplication. the ideal solution would be as i've described, that there were actually two different generic method protols (at least on the api level). a less ideal solution would be if we simply used contextl to define some copy-thing/copy-inner-class overrides in different layers and activate the given layer as needed. hm... if metacopy were integrated (via asdf-system-connections) with contextl then maybe we could keep the current copy-thing structure and provide macros that define the layered stuff and a toplevel entry point like the above mentioned clone-persistent-object transparently: (defcopyprotocol 'clone-persistent-object (super-copy-protocols)) (defcopymethod ((self type)) ...) where defcopyprotocol would define a 'clone-persistent-object and an internal layer inheriting the layers of the super-copy-protocols. then 'clone-persistent-object would enable that internal layer transparently and then call copy-thing. hm, if i didn't have several other things to do right now i would put together a prototype. opinions? -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Sat Oct 7 09:42:38 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sat, 7 Oct 2006 11:42:38 +0200 Subject: [metacopy-devel] another place where contextl is very handy Message-ID: Pascal, here's another good use of contextl: http://common-lisp.net/pipermail/metacopy-devel/2006-October/thread.html#0 only 3 mails, but in summary: there's a generic copy-thing protocol which is a one-fits-all copy protocol. but one could easily build some macrology on top of it for customized copy protocols that are the extension/customizations of the generic copy-thing protocol and/or other copy protocols. besides the usefulness i think this could be a very good demonstration of contextl. we need this, so i'll either work on metacopy to integrate with contextl (not likely, unless i find a way to integrate metacopy and contextl so that the contextl dependency is optional) or create a standalone metacopy-like package that depends on contextl. hoping you find this interesting, -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gwking at metabang.com Sat Oct 7 20:21:22 2006 From: gwking at metabang.com (Gary King) Date: Sat, 7 Oct 2006 16:21:22 -0400 Subject: [metacopy-devel] another place where contextl is very handy In-Reply-To: References: Message-ID: <7A424A33-8574-4198-9C52-0358E51A0C5C@metabang.com> Hi Attila, (I think that) This sounds like a very interesting idea. I'd like to hack it up myself but time is running away from me so I have doubts that I'll get to it. Please keep me in the loop. On Oct 7, 2006, at 5:42 AM, Attila Lendvai wrote: > > Pascal, here's another good use of contextl: > > http://common-lisp.net/pipermail/metacopy-devel/2006-October/ > thread.html#0 > > only 3 mails, but in summary: there's a generic copy-thing protocol > which is a one-fits-all copy protocol. but one could easily build > some macrology on top of it for customized copy protocols that are > the extension/customizations of the generic copy-thing protocol and/ > or other copy protocols. besides the usefulness i think this could > be a very good demonstration of contextl. we need this, so i'll > either work on metacopy to integrate with contextl (not likely, > unless i find a way to integrate metacopy and contextl so that the > contextl dependency is optional) or create a standalone metacopy- > like package that depends on contextl. > > hoping you find this interesting, > > -- > - attila > > "- The truth is that I've been too considerate, and so became > unintentionally cruel... > - I understand. > - No, you don't understand! We don't speak the same language!" > (Ingmar Bergman - Smultronst?llet) > _______________________________________________ > metacopy-devel mailing list > metacopy-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/metacopy-devel -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM -------------- next part -------------- An HTML attachment was scrubbed... URL: From pc at p-cos.net Sun Oct 8 10:35:15 2006 From: pc at p-cos.net (Pascal Costanza) Date: Sun, 8 Oct 2006 12:35:15 +0200 Subject: [metacopy-devel] Re: another place where contextl is very handy In-Reply-To: References: Message-ID: On 7 Oct 2006, at 11:42, Attila Lendvai wrote: > > Pascal, here's another good use of contextl: > > http://common-lisp.net/pipermail/metacopy-devel/2006-October/ > thread.html#0 > > only 3 mails, but in summary: there's a generic copy-thing protocol > which is a one-fits-all copy protocol. but one could easily build > some macrology on top of it for customized copy protocols that are > the extension/customizations of the generic copy-thing protocol and/ > or other copy protocols. Hm, of course I like it when people find uses for ContextL. However, wouldn't a separation into different copy functions be sufficient here? (So, having separate functions like deep-copy, shallow-copy, structure-copy, and so on?) Note: I don't enough about metacopy, so it's very likely that I am missing something here. > besides the usefulness i think this could be a very good > demonstration of contextl. we need this, so i'll either work on > metacopy to integrate with contextl (not likely, unless i find a > way to integrate metacopy and contextl so that the contextl > dependency is optional) or create a standalone metacopy-like > package that depends on contextl. Making ContextL optional is not straightforward because ContextL requires generic functions to be of the right metaclass, i.e., layered-function. In principle, CLOS specifices that you can change the metaclass of a generic function via change-class, but I am aware of only one CL implementation that actually implements this (that would be clisp), and I have doubts that this is a good idea in the first place. One idea would be to have a common entry point, roughly like this: (defun copy (&rest args) (declare (dynamic-extent args)) #+layered-copy (apply #'layered-copy args) #-layered-copy (apply #'generic-copy args)) With the right optimization settings, this shouldn't be too costly. > hoping you find this interesting, Yep. ;) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Mon Oct 16 18:06:59 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 16 Oct 2006 20:06:59 +0200 Subject: [metacopy-devel] Re: another place where contextl is very handy In-Reply-To: References: Message-ID: > > > only 3 mails, but in summary: there's a generic copy-thing protocol which > is a one-fits-all copy protocol. but one could easily build some macrology > on top of it for customized copy protocols that are the > extension/customizations of the generic copy-thing protocol and/or other > copy protocols. > > > Hm, of course I like it when people find uses for ContextL. However, > wouldn't a separation into different copy functions be sufficient here? (So, > having separate functions like deep-copy, shallow-copy, structure-copy, and > so on?) > > Note: I don't enough about metacopy, so it's very likely that I am missing > something here. > after some fighting with packages and asdf stuff here's what i came up with: (progn (define-copy-protocol adder-copy) (define-copy-protocol subber-copy) (define-copy-protocol list-element-duplicating-copy) (define-copy-protocol adder-and-list-element-duplicating-copy (adder-copy list-element-duplicating-copy)) (define-copy-method (copy-one adder-copy) ((n number) ht) (1+ n)) (define-copy-method (copy-one subber-copy) ((n number) ht) (1- n)) (define-copy-method (copy-one list-element-duplicating-copy) ((list cons) ht) (mapcan (lambda (el) (list (copy-thing el) (copy-thing el))) list)) (deftestsuite contextual (metacopy-test) () (:test ((ensure-same (adder-copy '(1 2)) '(2 3) :test #'equal))) (:test ((ensure-same (subber-copy '(2 3)) '(1 2) :test #'equal))) (:test ((ensure-same (list-element-duplicating-copy '(2 3)) '(2 2 3 3) :test #'equal))) (:test ((ensure-same (adder-and-list-element-duplicating-copy '(2 3)) '(3 3 4 4) :test #'equal))))) unfortunately the packaging took about 10 times the effort to do then the copy-protocol code. the trick is to load the metacopy code twice into two different packages, one is called metacopy-with-contextl. this way defgeneric and define-layered-function can live happily next to each other and everyone can chose between the contextl based, and therefore more heavyweight, stuff or the old defmethod way. i had to patch slime, asdf, and asdf-system-connections to make it work... one problem is left though: the way i'm using asdf is either illegal or there's some bug in asdf, because contextl and some other packages are reloaded even though they are not changed since i've last generated my sbcl core. it does not cause any problems, but... Making ContextL optional is not straightforward because ContextL requires > generic functions to be of the right metaclass, i.e., layered-function. In > principle, CLOS specifices that you can change the metaclass of a generic > function via change-class, but I am aware of only one CL implementation that > actually implements this (that would be clisp), and I have doubts that this > is a good idea in the first place. > > One idea would be to have a common entry point, roughly like this: > > (defun copy (&rest args) > (declare (dynamic-extent args)) > #+layered-copy (apply #'layered-copy args) > #-layered-copy (apply #'generic-copy args)) > this is the integration part: (in-package #.(metacopy-system:metacopy-package)) #+with-contextl (progn (defparameter *copy-protocols* nil "Holds a list of copy protocol names") (defun calculate-layer-name-from-protocol-name (name) (intern (concatenate 'string "%CPL-" (string name)))) (defmacro define-copy-protocol (name &optional super-protocols &rest options) "Define a copy protocol, which directly maps to a ContextL layer." `(progn (pushnew ',name *copy-protocols*) (deflayer ,(calculate-layer-name-from-protocol-name name) ,(mapcar #'calculate-layer-name-from-protocol-name super-protocols) , at options) (defun ,name (thing) (with-copy-protocol ,name (copy-thing thing))))) (defmacro define-copy-function (name args &rest options) "A defgeneric, with or without contextl." `(define-layered-function ,name ,args , at options)) (defmacro define-copy-method (name &rest body) "A defmethod, with or without contextl." (let ((protocol) (qualifiers) (args)) (when (consp name) (assert (= (length name) 2)) (setf protocol (calculate-layer-name-from-protocol-name (second name))) (setf name (first name))) (loop for el :in body until (consp el) do (push (pop body) qualifiers)) (setf args (pop body)) `(define-layered-method ,name ,@(when protocol `(:in-layer ,protocol)) , at qualifiers ,args , at body))) (defmacro with-copy-protocol (name &body body) (setf name (calculate-layer-name-from-protocol-name name)) `(with-active-layers (,name) , at body))) #-with-contextl (progn (defmacro define-copy-function (name args &rest options) "A defgeneric, with or without contextl." `(defgeneric ,name ,args , at options)) (defmacro define-copy-method (name args &rest options) "A defmethod, with or without contextl." (assert (not (consp name)) (name) "You can only define layered copy-methods with the metacopy-with-contextl package") `(defmethod ,name ,args , at options))) Gary, i hope you'll like it and help tailor out the asdf glitches (i forward some methods from one system to another after rebinding a variable without too deep asdf internals knowledge). i'll play a bit more with this and send you the patches, but it'll take some time until all the patches get into the repos. if you want to play with this before that just drop me a mail and i'll attach them all. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) -------------- next part -------------- An HTML attachment was scrubbed... URL: