From dirk at dirkgerrits.com Wed Jun 22 16:08:44 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Wed, 22 Jun 2005 18:08:44 +0200 Subject: [erlisp-devel] Now on GMANE. Message-ID: <42B98D0C.9080105@dirkgerrits.com> If all goes well, this e-mail should trigger the creation of the gmane.lisp.erlisp.devel newsgroup on news.gmane.org. The newsgroup is a bi-directional interface to the mailing list, so e-mails sent to either one will show up on both. Newsgroup lovers rejoice! ;) Kind regards, Dirk Gerrits From dirk at dirkgerrits.com Wed Jun 22 14:46:09 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Wed, 22 Jun 2005 16:46:09 +0200 Subject: [erlisp-devel] Now on GMANE. Message-ID: <42B979B1.6070507@dirkgerrits.com> If all goes well, this e-mail should trigger the creation of the gmane.lisp.erlisp.devel newsgroup on news.gmane.org. The newsgroup is a bi-directional interface to the mailing list, so e-mails sent to either one will show up on both. Newsgroup lovers rejoice! ;) Kind regards, Dirk Gerrits From dirk at dirkgerrits.com Thu Jun 23 09:06:26 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 23 Jun 2005 11:06:26 +0200 Subject: [erlisp-devel] Re: Now on GMANE. In-Reply-To: <42B98D0C.9080105@dirkgerrits.com> References: <42B98D0C.9080105@dirkgerrits.com> Message-ID: Dirk Gerrits wrote: > If all goes well, this e-mail should trigger the creation of the > gmane.lisp.erlisp.devel newsgroup on news.gmane.org. The newsgroup is > a bi-directional interface to the mailing list, so e-mails sent to > either one will show up on both. Newsgroup lovers rejoice! ;) Dirk Gerrits wrote: > If all goes well, this e-mail should trigger the creation of the > gmane.lisp.erlisp.devel newsgroup on news.gmane.org. The newsgroup is > a bi-directional interface to the mailing list, so e-mails sent to > either one will show up on both. Newsgroup lovers rejoice! ;) Hmm, I guess my first failed attempt didn't really fail at all... Oh well. Kind regards, Dirk Gerrits From lispnik at gmail.com Thu Jun 23 16:56:23 2005 From: lispnik at gmail.com (Ivan Boldyrev) Date: Thu, 23 Jun 2005 23:56:23 +0700 Subject: [erlisp-devel] Project goals Message-ID: Hi, Dirk! I have some questions on project goals. 1. Are you going to create something portable or SBCL/something else only? 2. Are you going to rely on some communication library such as PVM/MPI or something completely independent? 3. Do you have some plan or just experimenting / imitating Erlang? P.S. I am interested in parallel computation in Common Lisp. I have created UFFI bindings for PVM library. Though I do not remember exact URL of the project :) -- Ivan Boldyrev From dirk at dirkgerrits.com Thu Jun 23 17:46:51 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 23 Jun 2005 19:46:51 +0200 Subject: [erlisp-devel] Project goals In-Reply-To: References: Message-ID: <42BAF58B.9090708@dirkgerrits.com> Hi Ivan, Ivan Boldyrev wrote: > I have some questions on project goals. I've written quite a bit about Erlisp's goals in this roadmap: http://dirkgerrits.com/programming/erlisp/roadmap/ It's sort of the Erlisp manifesto. ;) > 1. Are you going to create something portable or SBCL/something else > only? Something portable, definately. I try to abstract away from all implementation specifics (see src/compatibility.lisp). Currently, only SBCL specifics are covered, but I do want to expand this in the future. (Patches are always welcome. ;)) > 2. Are you going to rely on some communication library such as > PVM/MPI or something completely independent? At the moment there is no need, as I'm "just" making an Erlang-clone. But when the time comes to go "beyond Erlang" (and it will), I may consider it. > 3. Do you have some plan or just experimenting / imitating Erlang? I do have a vague plan (see the roadmap), but mostly I'm just learning on the way. Imitating Erlang is the first step on the long road ahead. > P.S. I am interested in parallel computation in Common Lisp. I have > created UFFI bindings for PVM library. Though I do not remember exact > URL of the project :) Is it http://lispnik.newmail.ru/lpvm/ ? I haven't actually used PVM (and have only dabbled in MPI) but I'll try to take a look at it. Kind regards, Dirk Gerrits From lispnik at gmail.com Fri Jun 24 04:02:23 2005 From: lispnik at gmail.com (Ivan Boldyrev) Date: Fri, 24 Jun 2005 11:02:23 +0700 Subject: [erlisp-devel] Project goals In-Reply-To: <42BAF58B.9090708@dirkgerrits.com> (Dirk Gerrits's message of "Thu, 23 Jun 2005 19:46:51 +0200") References: <42BAF58B.9090708@dirkgerrits.com> Message-ID: On 9150 day of my life Dirk Gerrits wrote: >> P.S. I am interested in parallel computation in Common Lisp. I have >> created UFFI bindings for PVM library. Though I do not remember exact >> URL of the project :) > > Is it http://lispnik.newmail.ru/lpvm/ ? Yep. > I haven't actually used PVM (and have only dabbled in MPI) but I'll > try to take a look at it. PVM is older than MPI; key differences: PVM has simplier API, heterogeneousity and some degree of fault tolerancy. Perhaps it is better to build own library. Though PVM has at least two advantages: 1. We don't have to implement everything from scratch. 2. There are versions of PVM for specific communication hardware (e.g. Myrinet or ATM). -- Ivan Boldyrev Outlook has performed an illegal operation and will be shut down. If the problem persists, contact the program vendor. From aurelien.campeas at free.fr Sat Jun 25 18:28:40 2005 From: aurelien.campeas at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=) Date: Sat, 25 Jun 2005 20:28:40 +0200 Subject: [erlisp-devel] some thoughts ... Message-ID: <1119724120.20819.20.camel@localhost.localdomain> Hello Dirk & all, a) I have quickly skimmed over the current source and it seems that the important functionality of process linking is missing, isn't it ? b) I've also just read your "mop" section of the roadmap (section 2), where you want to investigate other avenues for parallelism than Erlang's one. I suggest reading what's made available by Mozart/Oz should give you most-important ideas about that. Erlang's concurrency is only one possibility in Oz, actually one of the more complex and powerful, but there is a whole scale of ways to go concurrent worth studying there. FYI, the Oz book is available there : http://www.ulb.ac.be/di/rwuyts/INFO020_2003/vanRoyHaridi2003-book.pdf It seems to me that wrt Oz, the parallel with the MOP is only superficial. On the other hand, I know one thing called "Agent-Group-Role" developped at lirmm which really looks like a mop for multi-agent systems (whatever that means, in fact agent there has to be seen as concurrent objects). You can have a first look at this : http://www.ualr.edu/kxaydin/Agents/From%20Agents%20to% 20Organizations.pdf I really had no time to allot to seriously playing with it but I intent to someday ... :) Cheers, Aur?lien. From dirk at dirkgerrits.com Sun Jun 26 10:42:42 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Sun, 26 Jun 2005 12:42:42 +0200 Subject: [erlisp-devel] some thoughts ... In-Reply-To: <1119724120.20819.20.camel@localhost.localdomain> References: <1119724120.20819.20.camel@localhost.localdomain> Message-ID: <42BE86A2.20800@dirkgerrits.com> Hi, Aur?lien Camp?as wrote: > a) I have quickly skimmed over the current source Cool. So what do you think? Anything you would have done differently? > and it seems that the important functionality of process linking is > missing, isn't it ? It is. I've done some thinking on it, but no coding yet. I first had (have?) to improve my knowledge of the Common Lisp Condition System [0], which is a whole other cup of tea than Erlang's. ;) By the way, linking is not the only bit of important functionality that's missing. Development is still at a very early stage, due to my busy school schedule over the past year. Hopefully this will be better during/after the coming summer. Also, it appears there will now be a Google-funded student working on Erlisp during the summer. [1] > b) I've also just read your "mop" section of the roadmap (section 2), > where you want to investigate other avenues for parallelism than > Erlang's one. > > I suggest reading what's made available by Mozart/Oz should give you > most-important ideas about that. Erlang's concurrency is only one > possibility in Oz, actually one of the more complex and powerful, but > there is a whole scale of ways to go concurrent worth studying there. Thanks for the suggestion, but I've already been pointed to Oz in the past. I have the Oz book, and it has been in the Erlisp references section for some time. So far I haven't had the time to read it all, but I've already been convinced that Oz and its concurrency aspects are worthy objects of study. > FYI, the Oz book is available there : > http://www.ulb.ac.be/di/rwuyts/INFO020_2003/vanRoyHaridi2003-book.pdf This is a draft right? My hardcover is from 2004. Still, a digital (searchable!) version is very handy. Thanks for the link! > It seems to me that wrt Oz, the parallel with the MOP is only > superficial. On the other hand, I know one thing called > "Agent-Group-Role" developped at lirmm which really looks like a mop for > multi-agent systems (whatever that means, in fact agent there has to be > seen as concurrent objects). You can have a first look at this : > http://www.ualr.edu/kxaydin/Agents/From%20Agents%20to% > 20Organizations.pdf Maybe it is my lack of knowledge on multi-agent systems, but I don't really see the MOP relation here. The CLOS MOP allows you to change the object system with which you build object oriented systems. The way I see it, AGR allows you to build multi-agent systems, but not change the way by which you do so. But again, I could be wrong; I'm the newbie here. ;) Oh but anyway, thanks for the link! > I really had no time to allot to seriously playing with it but I intent > to someday ... :) Are we still talking about AGR, or about Erlisp again? Either way, feel free to seriously play with either as much as you like, and let us know of your new-found insights. ;) Kind regards, Dirk Gerrits [0] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html [1] http://dirkgerrits.com/2005/06/26/9-lispnyc-summer-of-code-projects/ From sriram at malhar.net Mon Jun 27 06:13:32 2005 From: sriram at malhar.net (Sriram Srinivasan) Date: Sun, 26 Jun 2005 23:13:32 -0700 Subject: [erlisp-devel] Lightweight processes Message-ID: <635DC6BE-F05A-457E-AD40-8CCD27456A8A@malhar.net> Hello, I'd like to find out in some more detail how you intend to solve the lightweight process problem (or have you solved it already?). As far as I can see, an erlisp process is mapped directly to a SBCL thread, which in turn is a wrapper for an OS thread. This is exactly what erlang tries to get away from and what the erlang VM is geared to do differently. --Sriram. From sriram at malhar.net Mon Jun 27 07:25:54 2005 From: sriram at malhar.net (Sriram Srinivasan) Date: Mon, 27 Jun 2005 00:25:54 -0700 Subject: [erlisp-devel] Lightweight processes In-Reply-To: <653bea1605062623482eb5c158@mail.gmail.com> References: <635DC6BE-F05A-457E-AD40-8CCD27456A8A@malhar.net> <653bea1605062623482eb5c158@mail.gmail.com> Message-ID: <55825A28-315E-4F52-BDAC-5F2D0AF79A3B@malhar.net> On Jun 26, 2005, at 11:48 PM, Far? wrote: > One option would be to do global program transformation to CPS (as in > Screamer or UCW), some kind of ANF or even lower-level machine, and > thus provide interruptible lightweight green threads. Are you > interested in doing that? ok, good. I understand. I'm doing a similar project for java, so I won't be able to contribute directly to your effort directly at this point. Of course, it is "a little" more convenient to rewrite CL code into CPS, than it is to rewrite java byte-code. :( --Sriram. From aurelien.campeas at free.fr Mon Jun 27 08:20:21 2005 From: aurelien.campeas at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=) Date: Mon, 27 Jun 2005 10:20:21 +0200 Subject: [erlisp-devel] some thoughts ... In-Reply-To: <42BE86A2.20800@dirkgerrits.com> References: <1119724120.20819.20.camel@localhost.localdomain> <42BE86A2.20800@dirkgerrits.com> Message-ID: <1119860421.27550.41.camel@localhost.localdomain> Le dimanche 26 juin 2005 ? 12:42 +0200, Dirk Gerrits a ?crit : > Hi, > > Aur?lien Camp?as wrote: > > a) I have quickly skimmed over the current source > > Cool. So what do you think? Anything you would have done differently? I don't think much of it really :) It seems small and well structured for now, and to me, looks like an invitation to hack ... Apart from that, you seem to have put much effort into the pattern matcher/messaging part, which is good because I haven't had many thoughts about it. The fault tolerance aspect of erlang is more appealing to me ... (especially since I have been working on dependability/fault-tolerance in the past monthes) > > > and it seems that the important functionality of process linking is > > missing, isn't it ? > > It is. I've done some thinking on it, but no coding yet. I first had > (have?) to improve my knowledge of the Common Lisp Condition System [0], > which is a whole other cup of tea than Erlang's. ;) Exact. The condition system is one of the great beauties of CL, along with CLOS and a few other things :) I had the opportunity to study it last year and even afforded myself an entry in the (french, alas) wikipedia on the topic, trying to make it accessible to the non-specialist : http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_d% 27exceptions#Le_Syst.C3.A8me_de_Conditions_de_Common_Lisp I plan to detach it from exception handling and then translate it to english. > > By the way, linking is not the only bit of important functionality > that's missing. Development is still at a very early stage, due to my > busy school schedule over the past year. Hopefully this will be better > during/after the coming summer. Also, it appears there will now be a > Google-funded student working on Erlisp during the summer. [1] I've seen your announce, thanks to planet.lisp. That's just great, the google examiners really have good taste when it comes to selection of interesting projects ... ;-) > > > b) I've also just read your "mop" section of the roadmap (section 2), > > where you want to investigate other avenues for parallelism than > > Erlang's one. > > > > I suggest reading what's made available by Mozart/Oz should give you > > most-important ideas about that. Erlang's concurrency is only one > > possibility in Oz, actually one of the more complex and powerful, but > > there is a whole scale of ways to go concurrent worth studying there. > > Thanks for the suggestion, but I've already been pointed to Oz in the > past. I have the Oz book, and it has been in the Erlisp references > section for some time. So far I haven't had the time to read it all, > but I've already been convinced that Oz and its concurrency aspects are > worthy objects of study. > > > FYI, the Oz book is available there : > > http://www.ulb.ac.be/di/rwuyts/INFO020_2003/vanRoyHaridi2003-book.pdf > > This is a draft right? My hardcover is from 2004. Still, a digital > (searchable!) version is very handy. Thanks for the link! Maybe this is a draft, it looks nevertheless quite complete. > > > It seems to me that wrt Oz, the parallel with the MOP is only > > superficial. On the other hand, I know one thing called > > "Agent-Group-Role" developped at lirmm which really looks like a mop for > > multi-agent systems (whatever that means, in fact agent there has to be > > seen as concurrent objects). You can have a first look at this : > > http://www.ualr.edu/kxaydin/Agents/From%20Agents%20to% > > 20Organizations.pdf > > Maybe it is my lack of knowledge on multi-agent systems, but I don't > really see the MOP relation here. True, sorry, much of the relation still sits in my head right now :) Moreover, it is still quite fuzzy and may prove a stupid idea of mine when I reality-check it ... > The CLOS MOP allows you to change the object system with which you build > object oriented systems. True for CLOS, however changeability (full reflexion) is not necessarily what defines a MOP (in the general case) : it is merely a description of the object system in terms of (an instance of) itself. Compile- or Run-time modifiability of the system is a nice feature though. > > The way I see it, AGR allows you to build multi-agent systems, Precisely it defines a possible structuring of the interactions between agents. I would tend to write generic agent interactions like we write generic functions, with selection of the method (read : specific interaction) based on the tuple of the roles arguments ... Well the parallel with CLOS is maybe only superficial and surely, until now, resides mainly in my head ... > but not > change the way by which you do so. But again, I could be wrong; I'm the > newbie here. ;) I am very newbyish too, so the wrongness can be on my side. > > Oh but anyway, thanks for the link! > > > I really had no time to allot to seriously playing with it but I intent > > to someday ... :) > > Are we still talking about AGR, or about Erlisp again? Both, but I feel like going the Erlisp road first would be a good idea. In fact I was on the AGR road last year, while keeping an interested eye on Erlang, when you announced Erlisp, and I thought "that's it" ! AGR is quite abstract. Erlang offers something tangible, from a proven foundation and surely implementable. > Either way, feel > free to seriously play with either as much as you like, and let us know > of your new-found insights. ;) I must be honest here : I lack time and can't make any promise, even to myself, about when to do things. But when I get some, I know what I'll do :) It will be interesting to see what matures out of the google summer project, too. Cheers, Aur?lien > Kind regards, > > Dirk Gerrits > > [0] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html You surely have noted the previous one I suppose : http://www.nhplace.com/kent/Papers/Exceptional-Situations-1990.html Good reading ! From dirk at dirkgerrits.com Mon Jun 27 13:38:21 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Mon, 27 Jun 2005 15:38:21 +0200 Subject: [erlisp-devel] Lightweight processes In-Reply-To: <55825A28-315E-4F52-BDAC-5F2D0AF79A3B@malhar.net> References: <635DC6BE-F05A-457E-AD40-8CCD27456A8A@malhar.net> <653bea1605062623482eb5c158@mail.gmail.com> <55825A28-315E-4F52-BDAC-5F2D0AF79A3B@malhar.net> Message-ID: <42C0014D.9020902@dirkgerrits.com> > On Jun 26, 2005, at 11:48 PM, Far? wrote: > >> One option would be to do global program transformation to CPS (as >> in Screamer or UCW), Yes CPS is the option I'm currently pursuing. But it is far from ideal (no pre-emption in standard functions for example). Eventually there will have to be some implementation hacking and/or CLRFI'ing... >> some kind of ANF or even lower-level machine, and thus provide >> interruptible lightweight green threads. Indeed. Sriram Srinivasan wrote: > ok, good. I understand. I'm doing a similar project for java, so I > won't be able to contribute directly to your effort directly at this > point. > > Of course, it is "a little" more convenient to rewrite CL code into > CPS, than it is to rewrite java byte-code. :( The biggest problem with CPS in CL is (as far as I'm concerned) that you can only do it to your own code, and not the implementation's. So in CPS-Erlisp you'll probably want to write (loop for x in very-long-list collect (f x)) rather than (mapcar #'f very-long-list) (That is, if pre-emption is important for this operation.) A compromise can be reached by using multiple threads with several of these "CPS processes" per thread. That's basically the road I plan to pursue first. But I'm not sure what "my" Summer of Code student is going to do, or in fact who he/she is... Kind regards, Dirk Gerrits From dirk at dirkgerrits.com Mon Jun 27 13:58:23 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Mon, 27 Jun 2005 15:58:23 +0200 Subject: [erlisp-devel] some thoughts ... In-Reply-To: <1119860421.27550.41.camel@localhost.localdomain> References: <1119724120.20819.20.camel@localhost.localdomain> <42BE86A2.20800@dirkgerrits.com> <1119860421.27550.41.camel@localhost.localdomain> Message-ID: <42C005FF.8080102@dirkgerrits.com> Aur?lien Camp?as wrote: > Le dimanche 26 juin 2005 ? 12:42 +0200, Dirk Gerrits a ?crit : > > Exact. The condition system is one of the great beauties of CL, along > with CLOS and a few other things :) I had the opportunity to study it > last year and even afforded myself an entry in the (french, alas) > wikipedia on the topic, trying to make it accessible to the > non-specialist : > > http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_d% > 27exceptions#Le_Syst.C3.A8me_de_Conditions_de_Common_Lisp > > I plan to detach it from exception handling and then translate it to > english. Oh great. It looks like a really nice article, but my French is rather limited. The fish doesn't do too bad though. (http://tinyurl.com/bjmma) >> Also, it appears there will now be a Google-funded student working >> on Erlisp during the summer. [1]> > > I've seen your announce, thanks to planet.lisp. That's just great, the > google examiners really have good taste when it comes to selection of > interesting projects ... ;-) Not everyone thinks so, but I have nothing to complain about. ;) >>The CLOS MOP allows you to change the object system with which you build >>object oriented systems. > > > True for CLOS, however changeability (full reflexion) is not necessarily > what defines a MOP (in the general case) : it is merely a description of > the object system in terms of (an instance of) itself. Compile- or > Run-time modifiability of the system is a nice feature though. I think that's more or less a given for a system defined in itself. After all, you give the user the same system you built the system with. ;) >>>I really had no time to allot to seriously playing with it but I intent >>>to someday ... :) >> >>Are we still talking about AGR, or about Erlisp again? > > > Both, but I feel like going the Erlisp road first would be a good idea. > In fact I was on the AGR road last year, while keeping an interested eye > on Erlang, when you announced Erlisp, and I thought "that's it" ! AGR is > quite abstract. Erlang offers something tangible, from a proven > foundation and surely implementable. Wow, that's great to hear. :) >> Either way, feel free to seriously play with either as much as you >> like, and let us know of your new-found insights. ;) > > > I must be honest here : I lack time and can't make any promise, even to > myself, about when to do things. But when I get some, I know what I'll > do :) Time is a harsh mistress. ;) > It will be interesting to see what matures out of the google summer > project, too. Yes, and the other ones too. Some exciting things are happening in FFI-land, and it seems there's going to be a portable socket library for Erlisp too rely on too. ;) Kind regards, Dirk Gerrits >>[0] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html > > > You surely have noted the previous one I suppose : > > http://www.nhplace.com/kent/Papers/Exceptional-Situations-1990.html > > Good reading ! Yes, but thanks for the reminder. From aurelien.campeas at free.fr Tue Jun 28 09:05:39 2005 From: aurelien.campeas at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=) Date: Tue, 28 Jun 2005 11:05:39 +0200 Subject: [erlisp-devel] coroutine revival paper Message-ID: <1119949539.6314.17.camel@localhost.localdomain> In LTU today, this paper could be of interest for the erlisp bibliography : "Revisiting coroutines" ftp://ftp.inf.puc-rio.br/pub/docs/techreports/04_15_moura.pdf is a nice read (and I really like the notion of coroutines, but that's just me). Have a nice day, Aur?lien. From dirk at dirkgerrits.com Tue Jun 28 12:20:58 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Tue, 28 Jun 2005 14:20:58 +0200 Subject: [erlisp-devel] coroutine revival paper In-Reply-To: <1119949539.6314.17.camel@localhost.localdomain> References: <1119949539.6314.17.camel@localhost.localdomain> Message-ID: <42C140AA.8070204@dirkgerrits.com> Aur?lien Camp?as wrote: > In LTU today, this paper could be of interest for the erlisp > bibliography : "Revisiting coroutines" > ftp://ftp.inf.puc-rio.br/pub/docs/techreports/04_15_moura.pdf is a nice > read Thanks alot for the link! I read LtU though, so I would have seen it on my daily links routine. ;) > (and I really like the notion of coroutines, but that's just me). Same here, it's not just you. Kind regards, Dirk Gerrits From aurelien.campeas at free.fr Tue Jun 28 14:07:56 2005 From: aurelien.campeas at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=) Date: Tue, 28 Jun 2005 16:07:56 +0200 Subject: [erlisp-devel] coroutine revival paper In-Reply-To: <42C140AA.8070204@dirkgerrits.com> References: <1119949539.6314.17.camel@localhost.localdomain> <42C140AA.8070204@dirkgerrits.com> Message-ID: <1119967676.6314.48.camel@localhost.localdomain> Le mardi 28 juin 2005 ? 14:20 +0200, Dirk Gerrits a ?crit : > Aur?lien Camp?as wrote: > > In LTU today, this paper could be of interest for the erlisp > > bibliography : "Revisiting coroutines" > > ftp://ftp.inf.puc-rio.br/pub/docs/techreports/04_15_moura.pdf is a nice > > read > > Thanks alot for the link! I read LtU though, so I would have seen it on > my daily links routine. ;) I suspected it. Let us suppose I succombed to some form of 'first post' syndrome ... :) I've just seen this, btw : http://lisp-ecoop05.bknr.net/submission/19654 and wonder when that kind of material can be made available. From dirk at dirkgerrits.com Tue Jun 28 14:52:56 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Tue, 28 Jun 2005 16:52:56 +0200 Subject: [erlisp-devel] coroutine revival paper In-Reply-To: <1119967676.6314.48.camel@localhost.localdomain> References: <1119949539.6314.17.camel@localhost.localdomain> <42C140AA.8070204@dirkgerrits.com> <1119967676.6314.48.camel@localhost.localdomain> Message-ID: <42C16448.8050703@dirkgerrits.com> Aur?lien Camp?as wrote: > I've just seen this, btw : > > http://lisp-ecoop05.bknr.net/submission/19654 > > and wonder when that kind of material can be made available. Hmm I hadn't seen that paper yet, but Chris Newcombe had pointed me to these slides: http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20050216/termite.pdf I haven't found time to read either, but from skimming it looks interesting. Kind regards, Dirk Gerrits From lispnik at gmail.com Thu Jun 30 05:23:14 2005 From: lispnik at gmail.com (Ivan Boldyrev) Date: Thu, 30 Jun 2005 12:23:14 +0700 Subject: [erlisp-devel] Lightweight processes In-Reply-To: <42C0014D.9020902@dirkgerrits.com> (Dirk Gerrits's message of "Mon, 27 Jun 2005 15:38:21 +0200") References: <635DC6BE-F05A-457E-AD40-8CCD27456A8A@malhar.net> <653bea1605062623482eb5c158@mail.gmail.com> <55825A28-315E-4F52-BDAC-5F2D0AF79A3B@malhar.net> <42C0014D.9020902@dirkgerrits.com> Message-ID: On 9153 day of my life Dirk Gerrits wrote: > The biggest problem with CPS in CL is (as far as I'm concerned) that you > can only do it to your own code, and not the implementation's. So in > CPS-Erlisp you'll probably want to write > > (loop for x in very-long-list > collect (f x)) > > rather than > > (mapcar #'f very-long-list) Well, MAPCAR is easy to reimplement. Perhaps, it worth to implement special package ERCL, where such reimplemented functions will reside. And force users to use only that functions in Erlisp programs. ,---- | (in-package #:ercl-user) | | (defun test (f list) | (mapcar f list)) `---- Here DEFUN and MAPCAR are symbols from ERCL package, not CL. Erlisp will contain large subset of CL with some extenstions. Perhaps, it worth to create number of branchs with different approaches. It is experimental software (yet) anyway! > But I'm not sure what "my" Summer of Code student is going to do, or > in fact who he/she is... Well, I am not student at all :) -- Ivan Boldyrev From dirk at dirkgerrits.com Thu Jun 30 07:46:49 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 30 Jun 2005 09:46:49 +0200 Subject: [erlisp-devel] Lightweight processes In-Reply-To: References: <635DC6BE-F05A-457E-AD40-8CCD27456A8A@malhar.net> <653bea1605062623482eb5c158@mail.gmail.com> <55825A28-315E-4F52-BDAC-5F2D0AF79A3B@malhar.net> <42C0014D.9020902@dirkgerrits.com> Message-ID: <42C3A369.6060505@dirkgerrits.com> Ivan Boldyrev wrote: > On 9153 day of my life Dirk Gerrits wrote: > >>The biggest problem with CPS in CL is (as far as I'm concerned) that you >>can only do it to your own code, and not the implementation's. So in >>CPS-Erlisp you'll probably want to write >> >>(loop for x in very-long-list >> collect (f x)) >> >>rather than >> >>(mapcar #'f very-long-list) > > > Well, MAPCAR is easy to reimplement. Yes, but it is also easy to avoid. > Perhaps, it worth to implement special package ERCL, where such > reimplemented functions will reside. And force users to use only that > functions in Erlisp programs. > > ,---- > | (in-package #:ercl-user) > | > | (defun test (f list) > | (mapcar f list)) > `---- > > Here DEFUN and MAPCAR are symbols from ERCL package, not CL. > > Erlisp will contain large subset of CL with some extenstions. I have considered and rejected this approach. It's a lot of work (even when borrowing the code from an open-source Lisp implementation) and one gains very little. (More pre-emption in standard Common Lisp functions.) Also, this still won't fix all the other libraries out there that use :CL, not :ERCL. > Perhaps, it worth to create number of branchs with different > approaches. It is experimental software (yet) anyway! Certainly. Different branches/subdirectories/whatever can be used to try several strategies at once. Right now I'm experimenting with a CPS+trampolining approach on my laptop. At this point I don't know if it's going to work at all, so I haven't uploaded it yet. Once I'm more confident that it could be made to work I'll upload my patches. Kind regards, Dirk Gerrits