From attila.lendvai at gmail.com Tue May 11 21:04:30 2010 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 11 May 2010 23:04:30 +0200 Subject: [cl-walker-devel] hu.dwim.delico mailinglist In-Reply-To: References: Message-ID: > I was looking for a mailinglist for hu.dwim.delico or one for hu.dwim > in general, but could not find one. Where do I write to if I want to > ask stuff about hu.dwim.delico (in particular: serializing lambda's > does not seem to work)? hi! i think the closest match is http://common-lisp.net/mailman/listinfo/cl-walker-devel but i'm considering setting up a google group for all the dwim packages and use that until the traffic grows too high. or maybe i should set up mailing lists on dwim.hu? too much effort in the age od spam i guess... but meanwhile cl-walker-devel will do. -- attila From thomas.karolski at googlemail.com Wed May 12 15:12:29 2010 From: thomas.karolski at googlemail.com (Thomas Karolski) Date: Wed, 12 May 2010 17:12:29 +0200 Subject: [cl-walker-devel] [delico] Persistency with restart-case/handler-case/restart-bind/handler-bind Message-ID: Hi, I was trying to get persistent continuations using hu.dwim.delico, alas it turns out to be troublesome since SBCL internally uses closures to achieve this. Since most of the condition system commands are macros, I'd like to know whether it is possible to write custom macros for the walker which try not to depend on closures. I've tried the following examples: (defun/cc test/restarts/2 () "Not persistent. But restarts. Closure somewhere." (restart-case (progn (yield 'eatin) (error "No more to eat!")) (stop-eatin () :report "Stop eating and end script" nil))) (defun/cc test/restarts/4 () "Persistent. But restart not registered." (restart-case (with-call/cc (yield 'eatin) (error "No more to eat!")) (stop-eatin () :report "Stop eating and end script" nil))) (defun test/restarts/6 () "Persistent. But restarts not working. Probably because the with-call/cc lexical environment has the old restarts bound." (restart-case (with-call/cc (yield) (yield) (error "blaa2")) (return-with-nil () nil))) (defun test/restarts/7 () "Persistent, but handler not working." (handler-case (with-call/cc (yield) (yield) (error "blaa2")) (error () nil))) (defun/cc test/restarts/8 () "Persistent, but handler not working." (handler-case (with-call/cc ;; if progn here: no persistency (yield) (yield) (error "blaa2")) (error () nil))) From attila.lendvai at gmail.com Wed May 12 17:51:46 2010 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Wed, 12 May 2010 19:51:46 +0200 Subject: [cl-walker-devel] [delico] Persistency with restart-case/handler-case/restart-bind/handler-bind In-Reply-To: References: Message-ID: hi! > I was trying to get persistent continuations using hu.dwim.delico, > alas it turns out to be troublesome since SBCL internally uses > closures to achieve this. the problem is that restarts and condition handlers should be reimplemented and CPS transformed by delico because in the current setup it does not walk 'cl:signal and friends. and because of that we leave the delimited continuation area when they are called from CPS transformed code. it would be nice to have the same condition system in walked and non-walked code where conditions could enter and leave the delimited continuation area intact. as of the details of how to implement it... i don't have a worked out idea. conditions instantiated inside the cc area by a CPS transformed condition system implementation could leave the cc area on the top of the stack (if it's growing downwards). the custom condition/cc instances could contain the native conditions which would be re-thrown into the lisp's condition system when leaving the top of the cc area. as of native conditions thrown while outside the cc area on the bottom of the stack... maybe we could install handlers around the native calls leaving the cc area, then resignal stuff in the cc condition system, then ... ... ... it is getting messy, or i just simply didn't spend enough time refining the details. the point is: either try not to use conditions and/or restarts inside walked code, or alternatively work out the details of how to cross the cc borders. we are not planning to work on this in the near future. > Since most of the condition system commands are macros, I'd like to > know whether it is possible to write custom macros for the walker > which try not to depend on closures. you can customize the walker in very flexible ways. e.g. using it to compile a lisp dialect to javascript. examples here: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.quasi-quote;a=headblob;f=/source/js/syntax.lisp -- attila From thomas.karolski at googlemail.com Thu May 13 09:17:48 2010 From: thomas.karolski at googlemail.com (Thomas Karolski) Date: Thu, 13 May 2010 11:17:48 +0200 Subject: [cl-walker-devel] [delico] Persistency with restart-case/handler-case/restart-bind/handler-bind In-Reply-To: References: Message-ID: While reading your mail I realised that I do not know anything about the internals of delico or how it is working at all. Which is why I was hoping for a tutorial to operating the worker, since, well... docs are really very sparse. I'm already struggling understanding the different semantics of .def and I see that this is necessary in order to understand .walker. I'll see how far I can get. Thanks for the response. 2010/5/12 Attila Lendvai : > hi! > > >> I was trying to get persistent continuations using hu.dwim.delico, >> alas it turns out to be troublesome since SBCL internally uses >> closures to achieve this. > > > the problem is that restarts and condition handlers should be > reimplemented and CPS transformed by delico because in the current > setup it does not walk 'cl:signal and friends. and because of that we > leave the delimited continuation area when they are called from CPS > transformed code. > > it would be nice to have the same condition system in walked and > non-walked code where conditions could enter and leave the delimited > continuation area intact. > > as of the details of how to implement it... i don't have a worked out idea. > > conditions instantiated inside the cc area by a CPS transformed > condition system implementation could leave the cc area on the top of > the stack (if it's growing downwards). the custom condition/cc > instances could contain the native conditions which would be re-thrown > into the lisp's condition system when leaving the top of the cc area. > > as of native conditions thrown while outside the cc area on the bottom > of the stack... maybe we could install handlers around the native > calls leaving the cc area, then resignal stuff in the cc condition > system, then ... ... ... it is getting messy, or i just simply didn't > spend enough time refining the details. > > the point is: either try not to use conditions and/or restarts inside > walked code, or alternatively work out the details of how to cross the > cc borders. we are not planning to work on this in the near future. > > >> Since most of the condition system commands are macros, I'd like to >> know whether it is possible to write custom macros for the walker >> which try not to depend on closures. > > > you can customize the walker in very flexible ways. e.g. using it to > compile a lisp dialect to javascript. examples here: > > http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.quasi-quote;a=headblob;f=/source/js/syntax.lisp > > -- > ?attila > From attila.lendvai at gmail.com Thu May 13 09:34:49 2010 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 13 May 2010 11:34:49 +0200 Subject: [cl-walker-devel] [delico] Persistency with restart-case/handler-case/restart-bind/handler-bind In-Reply-To: References: Message-ID: > different semantics of .def and I see that this is necessary in order if you mean stuff like (def function ...) then there's no semantic difference there, just a think macro layer. (def definer ...) is really just a defmacro. also note that macroexpanding (def ...) forms works as expected. > to understand .walker. I'll see how far I can get. as of understanding how delimited CPS transformed code can/should interact with non-CPS transformed code is (i think) still subject to research. so, if you're looking for a PHD topic... ;) anyways, good luck with the exploration! -- attila PS: you can also reach us on IRC on #lisp