From kreuter at progn.net Wed Jun 21 02:54:35 2006 From: kreuter at progn.net (Richard M Kreuter) Date: Tue, 20 Jun 2006 22:54:35 -0400 Subject: [closer-devel] lispworks package, lw-compat system? Message-ID: <87wtbb5ic4.fsf@progn.net> Hi, The latest Closer to MOP available for asdf-install can't compile on sbcl or clisp (at least), evidently because of a mising lw-compat system, which I assume defines a LISPWORKS package (since every mop-packages.lisp's defpackage :uses :lispworks). What am I missing? Thanks, RmK $ grep -ir ":lw-compat" * closer-mop.asd: :depends-on (#-lispworks #:lw-compat) $ grep -ir ":lispworks" * allegro/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) clisp/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) ecl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) features.lisp::lispworks4.4 lispworks/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) mcl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) pcl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) From nickb42 at gmail.com Wed Jun 21 08:05:45 2006 From: nickb42 at gmail.com (Nick Bourner) Date: Wed, 21 Jun 2006 09:05:45 +0100 Subject: [closer-devel] lispworks package, lw-compat system? In-Reply-To: <87wtbb5ic4.fsf@progn.net> References: <87wtbb5ic4.fsf@progn.net> Message-ID: <17e6dce0606210105j1b8313bere5e7fdccd1fe50e9@mail.gmail.com> You should be able to get the lw-compat code from the darcs repo at http://common-lisp.net/project/closer/repos/lw-compat It all worked fine on sbcl the last time I tried it, although I didn't use adsf-install, just downloaded it and used asdf. Regards, Nick On 6/21/06, Richard M Kreuter wrote: > Hi, > > The latest Closer to MOP available for asdf-install can't compile on > sbcl or clisp (at least), evidently because of a mising lw-compat > system, which I assume defines a LISPWORKS package (since every > mop-packages.lisp's defpackage :uses :lispworks). > > What am I missing? > > Thanks, > RmK > > $ grep -ir ":lw-compat" * > closer-mop.asd: :depends-on (#-lispworks #:lw-compat) > $ grep -ir ":lispworks" * > allegro/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > clisp/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > ecl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > features.lisp::lispworks4.4 > lispworks/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > mcl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > pcl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > > _______________________________________________ > closer-devel mailing list > closer-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel > From gwking at metabang.com Wed Jun 21 13:00:56 2006 From: gwking at metabang.com (Gary King) Date: Wed, 21 Jun 2006 09:00:56 -0400 Subject: [closer-devel] lispworks package, lw-compat system? In-Reply-To: <87wtbb5ic4.fsf@progn.net> References: <87wtbb5ic4.fsf@progn.net> Message-ID: <0967633B-4D92-4810-9869-7A081E2BB306@metabang.com> Hi Richard, I maintain the ASDF-Installable versions of Closer to MOP so if there's any issue, it would be my bad. As far as I can tell, ASDF- Install is working correctly for Closer to MOP. ASDF-Install is _supposed_ to pull in dependencies when it grabs a system. Can you describe how you got Closer to MOP originally? thanks, On Jun 20, 2006, at 10:54 PM, Richard M Kreuter wrote: > Hi, > > The latest Closer to MOP available for asdf-install can't compile on > sbcl or clisp (at least), evidently because of a mising lw-compat > system, which I assume defines a LISPWORKS package (since every > mop-packages.lisp's defpackage :uses :lispworks). > > What am I missing? > > Thanks, > RmK > > $ grep -ir ":lw-compat" * > closer-mop.asd: :depends-on (#-lispworks #:lw-compat) > $ grep -ir ":lispworks" * > allegro/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > clisp/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > ecl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > features.lisp::lispworks4.4 > lispworks/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > mcl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > pcl/closer-mop-packages.lisp: (:use #:common-lisp #:lispworks) > > _______________________________________________ > closer-devel mailing list > closer-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel -- Gary Warren King metabang.com http://www.metabang.com/ (413) 210 7511 gwking on #lisp (occasionally) From kreuter at progn.net Wed Jun 21 13:47:20 2006 From: kreuter at progn.net (Richard M Kreuter) Date: Wed, 21 Jun 2006 09:47:20 -0400 Subject: [closer-devel] Re: lispworks package, lw-compat system? References: <87wtbb5ic4.fsf@progn.net> <0967633B-4D92-4810-9869-7A081E2BB306@metabang.com> Message-ID: <87psh262on.fsf@progn.net> Gary King writes: > As far as I can tell, ASDF-Install is working correctly for Closer > to MOP. ASDF-Install is _supposed_ to pull in dependencies when it > grabs a system. Can you describe how you got Closer to MOP > originally? Oh, how embarrassing. I've been moving things around between hosts, and probably lost something along the way. I inferred falsely from the fact that things used to work that I somehow got a newer closer-mop than one I had before, and generally got myself confused. Sorry for the bother. -- RmK From gwking at metabang.com Wed Jun 21 16:03:18 2006 From: gwking at metabang.com (Gary King) Date: Wed, 21 Jun 2006 12:03:18 -0400 Subject: [closer-devel] Re: lispworks package, lw-compat system? In-Reply-To: <87psh262on.fsf@progn.net> References: <87wtbb5ic4.fsf@progn.net> <0967633B-4D92-4810-9869-7A081E2BB306@metabang.com> <87psh262on.fsf@progn.net> Message-ID: Not to worry. All these dependencies get pretty crazy. it's harder that it should be. On Jun 21, 2006, at 9:47 AM, Richard M Kreuter wrote: > Gary King writes: > >> As far as I can tell, ASDF-Install is working correctly for Closer >> to MOP. ASDF-Install is _supposed_ to pull in dependencies when it >> grabs a system. Can you describe how you got Closer to MOP >> originally? > > Oh, how embarrassing. I've been moving things around between hosts, > and probably lost something along the way. I inferred falsely from > the fact that things used to work that I somehow got a newer > closer-mop than one I had before, and generally got myself confused. > Sorry for the bother. -- Gary Warren King metabang.com http://www.metabang.com/ (413) 210 7511 gwking on #lisp (occasionally) From pc at p-cos.net Wed Jun 21 16:47:30 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 21 Jun 2006 18:47:30 +0200 Subject: [closer-devel] Re: lispworks package, lw-compat system? In-Reply-To: References: <87wtbb5ic4.fsf@progn.net> <0967633B-4D92-4810-9869-7A081E2BB306@metabang.com> <87psh262on.fsf@progn.net> Message-ID: Harder in what sense? Do you mean the general ASDF infrastructure, or do you have suggestions how the specific Closer to MOP infrastructure could be improved? Pascal On 21 Jun 2006, at 18:03, Gary King wrote: > Not to worry. All these dependencies get pretty crazy. it's harder > that it should be. > > On Jun 21, 2006, at 9:47 AM, Richard M Kreuter wrote: > >> Gary King writes: >> >>> As far as I can tell, ASDF-Install is working correctly for Closer >>> to MOP. ASDF-Install is _supposed_ to pull in dependencies when it >>> grabs a system. Can you describe how you got Closer to MOP >>> originally? >> >> Oh, how embarrassing. I've been moving things around between hosts, >> and probably lost something along the way. I inferred falsely from >> the fact that things used to work that I somehow got a newer >> closer-mop than one I had before, and generally got myself confused. >> Sorry for the bother. > > -- > Gary Warren King > metabang.com > http://www.metabang.com/ > (413) 210 7511 > gwking on #lisp (occasionally) > > > _______________________________________________ > 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 gwking at metabang.com Wed Jun 21 17:37:37 2006 From: gwking at metabang.com (Gary King) Date: Wed, 21 Jun 2006 13:37:37 -0400 Subject: [closer-devel] Re: lispworks package, lw-compat system? In-Reply-To: References: <87wtbb5ic4.fsf@progn.net> <0967633B-4D92-4810-9869-7A081E2BB306@metabang.com> <87psh262on.fsf@progn.net>

Message-ID: Whoopts, My statement made it sound as if there was something about Closer that could be easier and that's not what I meant. I was speaking about the ASDF infrastructure in general: too many files in too many places so that it is too easy to lose track of things and not be sure of what to do to correct them. I think that the infrastructure needs to be improved. Closer et. al. is great! My apologies for any confusion or consternation. On Jun 21, 2006, at 12:47 PM, Pascal Costanza wrote: > Harder in what sense? Do you mean the general ASDF infrastructure, > or do you have suggestions how the specific Closer to MOP > infrastructure could be improved? > > Pascal > > On 21 Jun 2006, at 18:03, Gary King wrote: > >> Not to worry. All these dependencies get pretty crazy. it's harder >> that it should be. >> >> On Jun 21, 2006, at 9:47 AM, Richard M Kreuter wrote: >> >>> Gary King writes: >>> >>>> As far as I can tell, ASDF-Install is working correctly for Closer >>>> to MOP. ASDF-Install is _supposed_ to pull in dependencies when it >>>> grabs a system. Can you describe how you got Closer to MOP >>>> originally? >>> >>> Oh, how embarrassing. I've been moving things around between hosts, >>> and probably lost something along the way. I inferred falsely from >>> the fact that things used to work that I somehow got a newer >>> closer-mop than one I had before, and generally got myself confused. >>> Sorry for the bother. >> >> -- >> Gary Warren King >> metabang.com >> http://www.metabang.com/ >> (413) 210 7511 >> gwking on #lisp (occasionally) >> >> >> _______________________________________________ >> 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 > > > > -- Gary Warren King metabang.com http://www.metabang.com/ (413) 210 7511 gwking on #lisp (occasionally) From pc at p-cos.net Wed Jun 21 18:02:16 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 21 Jun 2006 20:02:16 +0200 Subject: [closer-devel] Re: lispworks package, lw-compat system? In-Reply-To: References: <87wtbb5ic4.fsf@progn.net> <0967633B-4D92-4810-9869-7A081E2BB306@metabang.com> <87psh262on.fsf@progn.net>

Message-ID: <8A490E0B-D428-4403-BC20-D1DC5EDB6972@p-cos.net> On 21 Jun 2006, at 19:37, Gary King wrote: > Whoopts, > > My statement made it sound as if there was something about Closer > that could be easier and that's not what I meant. I was speaking > about the ASDF infrastructure in general: too many files in too > many places so that it is too easy to lose track of things and not > be sure of what to do to correct them. I think that the > infrastructure needs to be improved. Closer et. al. is great! > > My apologies for any confusion or consternation. No problem at all! I am just interested in such kind of feedback, so I wanted to make sure that I didn't miss anything. At any time, feel free to criticize aspects related to this project... Cheers, Pascal > On Jun 21, 2006, at 12:47 PM, Pascal Costanza wrote: > >> Harder in what sense? Do you mean the general ASDF infrastructure, >> or do you have suggestions how the specific Closer to MOP >> infrastructure could be improved? >> >> Pascal >> >> On 21 Jun 2006, at 18:03, Gary King wrote: >> >>> Not to worry. All these dependencies get pretty crazy. it's >>> harder that it should be. >>> >>> On Jun 21, 2006, at 9:47 AM, Richard M Kreuter wrote: >>> >>>> Gary King writes: >>>> >>>>> As far as I can tell, ASDF-Install is working correctly for Closer >>>>> to MOP. ASDF-Install is _supposed_ to pull in dependencies when it >>>>> grabs a system. Can you describe how you got Closer to MOP >>>>> originally? >>>> >>>> Oh, how embarrassing. I've been moving things around between >>>> hosts, >>>> and probably lost something along the way. I inferred falsely from >>>> the fact that things used to work that I somehow got a newer >>>> closer-mop than one I had before, and generally got myself >>>> confused. >>>> Sorry for the bother. >>> >>> -- >>> Gary Warren King >>> metabang.com >>> http://www.metabang.com/ >>> (413) 210 7511 >>> gwking on #lisp (occasionally) >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> > > > -- > Gary Warren King > metabang.com > http://www.metabang.com/ > (413) 210 7511 > gwking on #lisp (occasionally) > > -- 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 jdunrue at gmail.com Fri Jun 23 00:33:23 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Thu, 22 Jun 2006 18:33:23 -0600 Subject: [closer-devel] starting work on a port to Corman Lisp Message-ID: I'm interested in getting Closer to MOP running on Corman Lisp (the next release of which is currently in beta). As a first step towards a port, I've started working through the MOP feature tests. I have one general question to start with -- are patches that provide workarounds for ANSI compliance problems acceptable? The first one I've encountered is that in CCL, delete-package simply signals an error with a "not implemented" string argument. I've sent feedback to the vendor on this. In the meantime, the simplest workaround is a hack (temporary packages would not get cleaned up), and so I'm wondering if a patch that disables the call to delete-package for CCL only be acceptable? Just trying to get a sense for how far it's reasonable to go in getting this port working vs. the understandable desire to keep your code sane. Thanks in advance for your thoughts. -- Jack Unrue From pc at p-cos.net Fri Jun 23 10:51:50 2006 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 23 Jun 2006 12:51:50 +0200 Subject: [closer-devel] starting work on a port to Corman Lisp In-Reply-To: References: Message-ID: <670779CC-6B79-4ABC-8026-84B1E9F3B9ED@p-cos.net> On 23 Jun 2006, at 02:33, Jack Unrue wrote: > I'm interested in getting Closer to MOP running on Corman Lisp (the > next > release of which is currently in beta). As a first step towards a > port, I've > started working through the MOP feature tests. > > I have one general question to start with -- are patches that provide > workarounds for ANSI compliance problems acceptable? The first one > I've encountered is that in CCL, delete-package simply signals an > error > with a "not implemented" string argument. I've sent feedback > to the vendor on this. In the meantime, the simplest workaround is a > hack (temporary packages would not get cleaned up), and so I'm > wondering > if a patch that disables the call to delete-package for CCL only be > acceptable? Fortunately, delete-package is only used in the test suite to provide a clean room for each test case. The simplest workaround I can think of is to provide a new package for each test case. (Currently, they all run in the same package, but between each run, that package is deleted and recreated again.) > Just trying to get a sense for how far it's reasonable to go in > getting this > port working vs. the understandable desire to keep your code sane. > Thanks > in advance for your thoughts. Before putting too much work into this, it would make more sense to first check whether a port of Closer to MOP to Corman Lisp is actually feasible. The last time I have checked, Corman Lisp's CLOS implementation was largely incompatible with the CLOS MOP spec. They have based their implementation on Closette, as provided in the AMOP book, and tweaked it to make it more ANSI-compliant. However, Closette is compatible with the CLOS MOP only in very few areas. Closer to MOP only provides fixes for CLOS implementations that attempt to be already somewhat close to the CLOS MOP specification. An attempt to fix an implementation that deviates too much doesn't make a lot of sense, because this would largely mean to more or less implement it from scratch. In that case, one could rather start to think about porting PCL. ;) So the interesting question is this: Has Corman Lisp considerably changed their CLOS implementation to be more CLOS-MOP-compliant? (Do you have a link/pointer available where I could check this?) 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 From pc at p-cos.net Fri Jun 23 10:56:25 2006 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 23 Jun 2006 12:56:25 +0200 Subject: [closer-devel] New paper about ContextL Message-ID: Hi, We have a new paper about ContextL at the forthcoming Joint Modular Languages Conference. We had to hand copyrights over to Springer Verlag, so I cannot publish it on my website for some time. But if anyone is interested, I can send you a copy. The paper discusses the implementation strategy for ContextL and gives a first performance benchmark. We basically show that ContextL programs are more or less as efficient as regular CLOS programs. The paper may give you some ideas on how to use the CLOS MOP. (However, we plan to write a paper which gives more details in this regard.) Warning: We have changed the Lisp syntax in that paper to a Java- style syntax to make it more accessible for a general audience. You sometimes have to jump through hoops. My plan is to publish an "uncensored" version of this paper sooner or later... ;) 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 From jdunrue at gmail.com Fri Jun 23 14:49:23 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Fri, 23 Jun 2006 08:49:23 -0600 Subject: [closer-devel] starting work on a port to Corman Lisp In-Reply-To: <670779CC-6B79-4ABC-8026-84B1E9F3B9ED@p-cos.net> References: <670779CC-6B79-4ABC-8026-84B1E9F3B9ED@p-cos.net> Message-ID: On 6/23/06, Pascal Costanza wrote: > > Fortunately, delete-package is only used in the test suite to provide > a clean room for each test case. The simplest workaround I can think > of is to provide a new package for each test case. (Currently, they > all run in the same package, but between each run, that package is > deleted and recreated again.) OK. > Before putting too much work into this, it would make more sense to > first check whether a port of Closer to MOP to Corman Lisp is > actually feasible. The last time I have checked, Corman Lisp's CLOS > implementation was largely incompatible with the CLOS MOP spec. They > have based their implementation on Closette, as provided in the AMOP > book, and tweaked it to make it more ANSI-compliant. However, > Closette is compatible with the CLOS MOP only in very few areas. > Closer to MOP only provides fixes for CLOS implementations that > attempt to be already somewhat close to the CLOS MOP specification. > An attempt to fix an implementation that deviates too much doesn't > make a lot of sense, because this would largely mean to more or less > implement it from scratch. In that case, one could rather start to > think about porting PCL. ;) Thanks for the info, I appreciate it. I was going to try porting Closer so that I could then work on porting my Graphic-Forms library to the new release of Corman. I use Closer in my code to define subclasses of an event handler base class and implement one or more methods for associated generic functions, on behalf of application code. So, in addition to possibly porting PCL (which I realize is potentially a major project not to be lightly taken on :-), another alternative is to change my code such that I don't use Closer any more -- but this means disrupting a feature that is working just fine on other Lisps. As a result, I'm probably going to prioritize Corman Lisp lower again and work on something else. > So the interesting question is this: Has Corman Lisp considerably > changed their CLOS implementation to be more CLOS-MOP-compliant? (Do > you have a link/pointer available where I could check this?) To get an "official" statement, I've posted a note to one of Corman's forums asking about this and will followup here with a link to any reply. But comments in the clos.lisp source file in the beta I have indicates that it is still based on Closette. -- Jack Unrue From pc at p-cos.net Thu Jun 29 09:49:27 2006 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 29 Jun 2006 11:49:27 +0200 Subject: [closer-devel] starting work on a port to Corman Lisp In-Reply-To: References: <670779CC-6B79-4ABC-8026-84B1E9F3B9ED@p-cos.net> Message-ID: <54EB1371-9420-472D-B524-FE25226B9F80@p-cos.net> On 23 Jun 2006, at 16:49, Jack Unrue wrote: > On 6/23/06, Pascal Costanza wrote: > >> >> Fortunately, delete-package is only used in the test suite to provide >> a clean room for each test case. The simplest workaround I can think >> of is to provide a new package for each test case. (Currently, they >> all run in the same package, but between each run, that package is >> deleted and recreated again.) >> > > OK. > > >> Before putting too much work into this, it would make more sense to >> first check whether a port of Closer to MOP to Corman Lisp is >> actually feasible. The last time I have checked, Corman Lisp's CLOS >> implementation was largely incompatible with the CLOS MOP spec. They >> have based their implementation on Closette, as provided in the AMOP >> book, and tweaked it to make it more ANSI-compliant. However, >> Closette is compatible with the CLOS MOP only in very few areas. >> Closer to MOP only provides fixes for CLOS implementations that >> attempt to be already somewhat close to the CLOS MOP specification. >> An attempt to fix an implementation that deviates too much doesn't >> make a lot of sense, because this would largely mean to more or less >> implement it from scratch. In that case, one could rather start to >> think about porting PCL. ;) >> > > Thanks for the info, I appreciate it. I was going to try porting > Closer > so that I could then work on porting my Graphic-Forms library to the > new release of Corman. > > I use Closer in my code to define subclasses of an event handler > base class and implement one or more methods for associated > generic functions, on behalf of application code. So, in addition > to possibly porting PCL (which I realize is potentially a major > project > not to be lightly taken on :-), another alternative is to change my > code such that I don't use Closer any more -- but this means > disrupting a feature that is working just fine on other Lisps. > > As a result, I'm probably going to prioritize Corman Lisp lower > again and work on something else. > Hm, hold your horses. ;) If these are indeed the only two features you need, they should probably be relatively straightforward to support. Because of my own work with the CLOS MOP, I typically think of the more advanced features of the CLOS MOP. But I start to get the impression that people find Closer to MOP useful for the very basic features - and that makes a lot of sense, of course. Maybe I should restructure the library to make it easier to distinguish the base features for which we can have at least some guarantee that all covered CLOS implementations support them, and the other more advanced ones. For example, the pure introspective features are covered very well almost everywhere. It's only the semantics-changing features especially in the generic function invocation protocol that are problematic across CLOS implementations - but that's also the part where there actually seems to be very little demand. Do people have any specific opinions wrt this topic? >> So the interesting question is this: Has Corman Lisp considerably >> changed their CLOS implementation to be more CLOS-MOP-compliant? (Do >> you have a link/pointer available where I could check this?) >> > > To get an "official" statement, I've posted a note to one of Corman's > forums asking about this and will followup here with a link to any > reply. > But comments in the clos.lisp source file in the beta I have indicates > that it is still based on Closette. > I would be surprised otherwise. Porting PCL _is_ a major undertaking. ;) 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 From jdunrue at gmail.com Thu Jun 29 14:30:00 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Thu, 29 Jun 2006 08:30:00 -0600 Subject: [closer-devel] starting work on a port to Corman Lisp In-Reply-To: <54EB1371-9420-472D-B524-FE25226B9F80@p-cos.net> References: <670779CC-6B79-4ABC-8026-84B1E9F3B9ED@p-cos.net> <54EB1371-9420-472D-B524-FE25226B9F80@p-cos.net> Message-ID: On 6/29/06, Pascal Costanza wrote: > > Hm, hold your horses. ;) If these are indeed the only two features > you need, they should probably be relatively straightforward to support. > > Because of my own work with the CLOS MOP, I typically think of the > more advanced features of the CLOS MOP. But I start to get the > impression that people find Closer to MOP useful for the very basic > features - and that makes a lot of sense, of course. Maybe I should > restructure the library to make it easier to distinguish the base > features for which we can have at least some guarantee that all > covered CLOS implementations support them, and the other more > advanced ones. > > For example, the pure introspective features are covered very well > almost everywhere. It's only the semantics-changing features > especially in the generic function invocation protocol that are > problematic across CLOS implementations - but that's also the part > where there actually seems to be very little demand. > > Do people have any specific opinions wrt this topic? I think breaking out a "basic functionality" subset is a good idea, and I'd be willing to help port and test (e.g., to Corman). We've discussed briefly the features that I'm using, hopefully others will chime in as well. Other than that, I don't have a good feel for where the boundary around this subset should be drawn. -- Jack Unrue From gwking at metabang.com Thu Jun 29 17:54:44 2006 From: gwking at metabang.com (Gary King) Date: Thu, 29 Jun 2006 13:54:44 -0400 Subject: [closer-devel] starting work on a port to Corman Lisp In-Reply-To: <54EB1371-9420-472D-B524-FE25226B9F80@p-cos.net> References: <670779CC-6B79-4ABC-8026-84B1E9F3B9ED@p-cos.net> <54EB1371-9420-472D-B524-FE25226B9F80@p-cos.net> Message-ID: <6EF76183-D738-4E13-85FA-57C4FCBDDF37@metabang.com> I think that having two or more reasonable conformance "levels" would make sense. I also think that breaking MOP support into introspection and semantics (implementation altering) makes sense. I don't know much of anything about the consistency of MOP implementations but it work to have something like (warning, ASCII art ahead): MOP Support | +-------------------- introspection | | | +-------------------- level 1 | +-------------------- level 2 | +-------------------- implementation | +-------------------- level 1 +-------------------- level 2 Where the levels lie will depend on how the MOP implementations carve "nature at its joints". That Plato, he had such a way with words. > Because of my own work with the CLOS MOP, I typically think of the > more advanced features of the CLOS MOP. But I start to get the > impression that people find Closer to MOP useful for the very basic > features - and that makes a lot of sense, of course. Maybe I should > restructure the library to make it easier to distinguish the base > features for which we can have at least some guarantee that all > covered CLOS implementations support them, and the other more > advanced ones. > > For example, the pure introspective features are covered very well > almost everywhere. It's only the semantics-changing features > especially in the generic function invocation protocol that are > problematic across CLOS implementations - but that's also the part > where there actually seems to be very little demand. -- Gary Warren King metabang.com http://www.metabang.com/ (413) 210 7511 gwking on #lisp (occasionally)