From MOP's description for COMPUTE-EFFECTIVE-METHOD,
http://www.lisp.org/mop/dictionary.html#compute-effective-method
> This generic function returns two values. The first is an effective
> method, the second is a list of effective method options.
For me, effective method options (actually the :arguments and the
:generic-function options given in the long form of
define-method-combination) seem to be of no or little use in this context.
Because all the processing involving these options are done inside of the
compute-effective-method body and the resulting effective method
is returned as the first value.
Could you tell me, who uses for what with this information?
Thanks, in advance.
Yuji Minejima wrote:
> From MOP's description for COMPUTE-EFFECTIVE-METHOD,
> http://www.lisp.org/mop/dictionary.html#compute-effective-method
>
>>This generic function returns two values. The first is an effective
>>method, the second is a list of effective method options.
>
> For me, effective method options (actually the :arguments and the
> :generic-function options given in the long form of
> define-method-combination) seem to be of no or little use in this context.
>
> Because all the processing involving these options are done inside of the
> compute-effective-method body and the resulting effective method
> is returned as the first value.
>
> Could you tell me, who uses for what with this information?
This part of the MOP specification is indeed very vague, so I can only
guess. But I think that it is useful for the call site to know what
method combination options the effective method actually uses, so that
the call site can decide to only provide those. It may even be required
that the call site knows about those options because, AFAICS, in a
method combination you can freely choose the names for the variables
that represent the gf and the arguments at execution time. But I haven't
checked this...
Does this help you?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Yuji Minejima
Subject: Yet Another CLOS implementation (Re: Use of the secondary return value of compute-effective-method)
Date:
Message-ID: <pan.2004.08.01.04.22.03.443612@nifty.ne.jp>
On Sat, 31 Jul 2004 11:46:19 +0200, Pascal Costanza wrote:
[the citation is reformatted.]
> This part of the MOP specification is indeed very vague, so I can only
> guess.
I feel the same.
> But I think that it is useful for the call site to know what
> method combination options the effective method actually uses, so that
> the call site can decide to only provide those.
I'm not sure if I get what you mean by "the call site", but the
method combination options are specified by someone who call the macro
define-method-combination and the values bound for those options'
variables are captured automatically when someone calls a generic function
whose discriminating function has not determined its effective method. So
those values need not be given explicitly.
> It may even be required that the call site knows about those options
> because, AFAICS, in a method combination you can freely choose the names
> for the variables that represent the gf and the arguments at execution time.
> But I haven't checked this...
Yes, names for those variables are chosen freely by the caller of
define-method-combination. But I think it's OK to think those scopes are
segregated within the body of the define-method-combination and its
production -- the effective method (which really is a form, not a method).
Considering call-effective-method can be overridden, I guess users of MOP
probably want to know these method combination options when they write
their custom call-effective-method. So it seems one step late that this
information appears on the MOP stage.
> Does this help you?
Yes, thanks. I'm currently writing an CLOS implementation with MOP fully
supported and it's encouraging to know there's someone who pays attention
to MOP even now.
The work is done roughly about 2/3. I'll put it public for this
opportunity. I appreciate if someone takes the time to read it and gives
me some comments, especially on its design.
Some points are,
* fully support MOP.
* portable (written in pure COMMON LISP, no specific implementation in
mind).
* code simplicity (readability) over performance, but caching
schemes suggested by MOP are included.
* ...
http://homepage1.nifty.com/bmonkey/lisp/sacla/clos.lisp
Cheers,
Yuji
From: Pascal Costanza
Subject: Re: Yet Another CLOS implementation (Re: Use of the secondary return value of compute-effective-method)
Date:
Message-ID: <cel7ul$t67$1@newsreader2.netcologne.de>
Yuji Minejima wrote:
> Considering call-effective-method can be overridden, I guess users of MOP
> probably want to know these method combination options when they write
> their custom call-effective-method. So it seems one step late that this
> information appears on the MOP stage.
Hm, maybe they had a similar use in mind as that of the second return
value for make-method-lambda - it allows you to communicate additional
information to the initialization code for a method metaobject. So if
you want to add new options to your own kind of method combination you
could make use of it in another place. However, this is pure
speculation. (There are postings to this newsgroup by Gregor Kiczales
10-15 years ago in which he admits that they haven't worked enough on
these details.)
> I'm currently writing an CLOS implementation with MOP fully
> supported and it's encouraging to know there's someone who pays attention
> to MOP even now.
Definitely. I think the MOP is pretty important, even though Kenny
disagrees. ;)
> The work is done roughly about 2/3. I'll put it public for this
> opportunity. I appreciate if someone takes the time to read it and gives
> me some comments, especially on its design.
I have skimmed through it very superficially, but it looks quite good.
Could you tell us what your concrete goals are, apart from the
advantages you have already listed? Is this just for fun, or do you want
to use it for a particular purpose?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Yuji Minejima
Subject: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <pan.2004.08.03.02.14.42.662286@nifty.ne.jp>
On Mon, 02 Aug 2004 13:18:45 +0200, Pascal Costanza wrote:
> I have skimmed through it very superficially, but it looks quite good.
> Could you tell us what your concrete goals are, apart from the
> advantages you have already listed? Is this just for fun, or do you want
> to use it for a particular purpose?
Thank you for your comment. Actually, I'm writing a Common Lisp
implementation called Sacla right now. The work done so far can be found
here. http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html
So I'll use this clos code in Sacla and probably port it to Xyzzy editor
which is an Emacs like editor with a partial Common Lisp interpeter as its
extension language. See http://www.jsdlab.co.jp/~kamei/ (This site is
written in Japanese.) And I might check Emacs-CL if it's possible to port
it to.
I use CLISP for testing environment. That makes it possible for
my code to take over CLISP's CLOS when it's finished, although I don't
know if it has any meaning.
My random thoughts on Sacla are,
* must be fun to write. More seriously, understand Common Lisp
through implementing it.
* determine small core Lisp functionalities which cannot be written
with others and implement the rest of the Lisp world using those. In
short, I want to write as much code in Lisp as possible. I haven't
decided how the core part should be materialized (by a byte-code
interpreter or a native code compiler, and the like). But someone has
already expressed his interest of writing a compiler for it.
* strict conformance to ANSI Common Lisp and other community
specifications (like MOP).
* performance must be achieved through simple and clear designs and code,
not ad hoc optimizations. (This might be a delusion or it's just a
matter of balance.)
* should be appropreate for scripting purposes. (like fast start up time.)
* license should be loose enough so that if someone gets interested in
some code of Sacla, I want her to feel free to use it. The current
license is so called 2 terms BSD license. I'm wondering if it's better
to place it in the public domain, or to retain all rights and grant the
user permission to slap her own license on it. I think I've heard
something about that BSD license doesn't get along with GPL.
There're many (trivial) things and (possibly silly) ideas I'd like to try
out. For example, sequence functions can be written much more clearly as
generic functions (although speed might suffer), utilizing a theorem prover
for code optimization (I must confess that I don't know much about theorem
provers right now), or writing implementation specific documentation in
the Common Lisp HyperSpec format (but change the background color).
Any comments are welcome.
Yuji
From: Hannah Schroeter
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <cenrs0$2vh$2@c3po.use.schlund.de>
Hello!
Yuji Minejima <········@nifty.ne.jp> wrote:
>On Mon, 02 Aug 2004 13:18:45 +0200, Pascal Costanza wrote:
>> I have skimmed through it very superficially, but it looks quite good.
>> Could you tell us what your concrete goals are, apart from the
>> advantages you have already listed? Is this just for fun, or do you want
>> to use it for a particular purpose?
>Thank you for your comment. Actually, I'm writing a Common Lisp
>implementation called Sacla right now. The work done so far can be found
>here. http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html
>[...]
>* license should be loose enough so that if someone gets interested in
> some code of Sacla, I want her to feel free to use it. The current
> license is so called 2 terms BSD license. I'm wondering if it's better
> to place it in the public domain, or to retain all rights and grant the
> user permission to slap her own license on it. I think I've heard
> something about that BSD license doesn't get along with GPL.
That's an old problem. Modern 3 or 2 clause BSD licenses (such as the
default OpenBSD one for their new code) don't have that problem, as it
was associated to the so called advertising clause of the original 4
clause license, which got/is getting more and more removed even from
older BSD code.
So I'd guess BSD license is very fine, if you intend to be that liberal.
It grants *almost* every rights of PD, but retains you the copyright
holder and you get credit where credit is due.
>[...]
Kind regards,
Hannah.
From: Pascal Costanza
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <censlo$1jp$1@newsreader2.netcologne.de>
Hannah Schroeter wrote:
>>* license should be loose enough so that if someone gets interested in
>> some code of Sacla, I want her to feel free to use it. The current
>> license is so called 2 terms BSD license. I'm wondering if it's better
>> to place it in the public domain, or to retain all rights and grant the
>> user permission to slap her own license on it. I think I've heard
>> something about that BSD license doesn't get along with GPL.
>
> That's an old problem. Modern 3 or 2 clause BSD licenses (such as the
> default OpenBSD one for their new code) don't have that problem, as it
> was associated to the so called advertising clause of the original 4
> clause license, which got/is getting more and more removed even from
> older BSD code.
See http://creativecommons.org/ for an alternative approach to
licensing. (See "Choose License".)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: ·········@random-state.net
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <ceoltj$4pq59$2@midnight.cs.hut.fi>
Pascal Costanza <········@web.de> wrote:
> See http://creativecommons.org/ for an alternative approach to
> licensing. (See "Choose License".)
For potential problems with Creative Commons licences see:
http://lists.debian.org/debian-legal/2004/04/msg00031.html
Why is nothing ever simple?
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
From: Rob Warnock
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <P_mdnVRTS9xpzY3cRVn-rA@speakeasy.net>
<·········@random-state.net> wrote:
+---------------
| Pascal Costanza <········@web.de> wrote:
| > See http://creativecommons.org/ for an alternative approach to
| > licensing. (See "Choose License".)
|
| For potential problems with Creative Commons licences see:
| http://lists.debian.org/debian-legal/2004/04/msg00031.html
+---------------
I agree. My suggestion is to use the "new" BSD license (or the
MIT/X license) if you feel you can, or the LLGPL ("Lisp LGPL")
license <http://opensource.franz.com/preamble.html> if you must.
Failing that, the LGPL or the GPL. Regardless of what anyone feels
about the desirability of using one of those, at least they are
very well known, and their implications are widely thought to be
understood. Anything else is just going create more confusion and
problems with interoperability and/or community contributions, IMHO.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Yuji Minejima
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <pan.2004.08.05.03.03.58.380321@nifty.ne.jp>
On Tue, 03 Aug 2004 21:59:00 -0500, Rob Warnock wrote:
> I agree. My suggestion is to use the "new" BSD license (or the
> MIT/X license) if you feel you can, or the LLGPL ("Lisp LGPL")
> license <http://opensource.franz.com/preamble.html> if you must.
> Failing that, the LGPL or the GPL. Regardless of what anyone feels
> about the desirability of using one of those, at least they are
> very well known, and their implications are widely thought to be
> understood. Anything else is just going create more confusion and
> problems with interoperability and/or community contributions, IMHO.
I just noticed that I was a bit behind the time when it comes to
licensing issues and decided to leave Sacla under 2 clause BSD license
(the "new" BSD license) for the time being while I study things around
these issues.
Thank you all.
Yuji.
From: Pascal Costanza
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <ceq7ct$a3v$1@newsreader2.netcologne.de>
·········@random-state.net wrote:
> Pascal Costanza <········@web.de> wrote:
>
>>See http://creativecommons.org/ for an alternative approach to
>>licensing. (See "Choose License".)
>
> For potential problems with Creative Commons licences see:
>
> http://lists.debian.org/debian-legal/2004/04/msg00031.html
Hm, thanks for the link. However, they discuss 1.0 of the Creative
Commons license. Maybe 2.0 solved those problems?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Yuji Minejima
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <pan.2004.08.04.04.29.48.802444@nifty.ne.jp>
On Tue, 03 Aug 2004 11:10:56 +0000, Hannah Schroeter wrote:
Hi.
I have read GPL and 2 clause BSD license for a few times and there's
something I still can't figure out. And I don't follow issues around
software licenses these days very eagerly.
("Creative Commons? Yeah, I've heard of that." level.)
Can someone take some code snippets away from one software placed under 2
clause BSD license written by others and incorporate it with her own
software licensed under GPL and release that under GPL again? Although
what GPL clauses request seems to cover what 2 caluse BSD license
requests, I can't say that it's OK with confidence. I believe the
opposite is impossible as GPL is stricter than 2 clause BSD license.
As for public domain, is it possible to change the license of some
software in the public domain and release that under another stricter
license, say GPL? ArmedBear Common Lisp which is recently announced here
seems to do this with CMUCL.
Yuji
From: Pascal Bourguignon
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <87wu0fxz9h.fsf@thalassa.informatimago.com>
Yuji Minejima <········@nifty.ne.jp> writes:
> On Tue, 03 Aug 2004 11:10:56 +0000, Hannah Schroeter wrote:
>
> Hi.
>
> I have read GPL and 2 clause BSD license for a few times and there's
> something I still can't figure out. And I don't follow issues around
> software licenses these days very eagerly.
> ("Creative Commons? Yeah, I've heard of that." level.)
>
> Can someone take some code snippets away from one software placed under 2
> clause BSD license written by others and incorporate it with her own
> software licensed under GPL and release that under GPL again? Although
> what GPL clauses request seems to cover what 2 caluse BSD license
> requests, I can't say that it's OK with confidence.
You'd have to write somewhere "some parts copyright Mr BSD Developer",
and obviously, since those parts have already been licensed under 2-
clause BSD, anybody could use them as they see fit under that 2-clause
BSD, so in effect, GPL would not apply to them.
> I believe the
> opposite is impossible as GPL is stricter than 2 clause BSD license.
> As for public domain, is it possible to change the license of some
> software in the public domain and release that under another stricter
> license, say GPL? ArmedBear Common Lisp which is recently announced here
> seems to do this with CMUCL.
You cannot put your own copyright on public domain software, so you
have no right to change the 'license' of public domain knowledge, but
you can still package and sell it as you want.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
From: Rob Warnock
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <WZ-dnb_7WNgZKo3cRVn-og@speakeasy.net>
Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
+---------------
| You cannot put your own copyright on public domain software, so you
| have no right to change the 'license' of public domain knowledge, but
| you can still package and sell it as you want.
+---------------
Actually, that's not true. (...at least, not in the U.S.) In fact, if
I recall the story correctly, that's precisely what started everyone
slapping copyrights on their open-source software back in the early
BSD days -- somebody took a public-domain editor, made a few small
changes, copyrighted it, then started suing people who were still
distributing the original public-domain version for violating their
copyright! At which point, a bunch of outraged people who had been
dedicating their software to the public domain began using modified
BSD copyrights instead. [The GPL came quite a bit later...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Mark Carter
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <2nc2bbFutu2pU1@uni-berlin.de>
Rob Warnock wrote:
> Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
> +---------------
> | You cannot put your own copyright on public domain software, so you
> | have no right to change the 'license' of public domain knowledge, but
> | you can still package and sell it as you want.
> +---------------
>
> Actually, that's not true. (...at least, not in the U.S.) In fact, if
> I recall the story correctly, that's precisely what started everyone
> slapping copyrights on their open-source software back in the early
> BSD days -- somebody took a public-domain editor, made a few small
> changes, copyrighted it, then started suing people who were still
> distributing the original public-domain version for violating their
> copyright!
You may be right, I wont argue with you. But there would appear, at
least in my eyes, to be no legal basis for a copyright breach. Surely,
if code is public domain, then it's public domain. I don't see how
creating a copyrighted derivative piece of code (even if that change is
as miniscule as one could possibly imagine) can in any way affect the PD
status of the original code.
Of course, if copyright code was made public and described as public
domain, then that's a different matter. Only the original copyright
holder can make it Public Domain.
So going back to the above, one could presumably put a copyright notice
on PD code, and then claim copyright of it. However, that wouldn't do
you much good, because people could simply use the PD version??
If not, then the US legal system appears to be in even worse shape than
I originally imagined.
From: Rob Warnock
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <m6idneYru-Wueo3cRVn-pQ@speakeasy.net>
Mark Carter <············@ukmail.com> wrote:
+---------------
| If not, then the US legal system appears to be in even worse shape than
| I originally imagined.
+---------------
And this surprises you?!?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Joe Marshall
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation
Date:
Message-ID: <isbz7yeu.fsf@ccs.neu.edu>
>> Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
>> +---------------
>> | You cannot put your own copyright on public domain software, so you
>> | have no right to change the 'license' of public domain knowledge, but
>> | you can still package and sell it as you want.
>> +---------------
> Rob Warnock wrote:
>> Actually, that's not true. (...at least, not in the U.S.) In fact, if
>> I recall the story correctly, that's precisely what started everyone
>> slapping copyrights on their open-source software back in the early
>> BSD days -- somebody took a public-domain editor, made a few small
>> changes, copyrighted it, then started suing people who were still
>> distributing the original public-domain version for violating their
>> copyright!
Mark Carter <············@ukmail.com> writes:
>
> So going back to the above, one could presumably put a copyright
> notice on PD code, and then claim copyright of it. However, that
> wouldn't do you much good, because people could simply use the PD
> version??
>
> If not, then the US legal system appears to be in even worse shape
> than I originally imagined.
The rule of law is this: no matter what the law says, no matter what
you do or fail to do, a suit may be filed against you. All that is
needed is a plausible rationale, and any lawyer will be happy to sell
one to you.
In *theory*, a suit with no basis would be instantly dismissed and the
plaintiff (and his lawyer) would get a stern lecture about abusing the
court system. This theory assumes that the plaintiff's lawyer
presents an objective view of the facts and cites the relevant case
law.
From: Yuji Minejima
Subject: Re: Sacla: Yet Another (partial) Common Lisp implementation (was Re: Yet Another CLOS implementation)
Date:
Message-ID: <pan.2004.08.04.07.18.58.189287@nifty.ne.jp>
On Wed, 04 Aug 2004 07:12:26 +0200, Pascal Bourguignon wrote:
> You'd have to write somewhere "some parts copyright Mr BSD Developer",
> and obviously, since those parts have already been licensed under 2-
> clause BSD, anybody could use them as they see fit under that 2-clause
> BSD, so in effect, GPL would not apply to them.
>
>
>> As for public domain, is it possible to change the license of some
>> software in the public domain and release that under another stricter
>> license, say GPL? ArmedBear Common Lisp which is recently announced here
>> seems to do this with CMUCL.
>
> You cannot put your own copyright on public domain software, so you
> have no right to change the 'license' of public domain knowledge, but
> you can still package and sell it as you want.
Thank you. Things are getting clearer in my head.
I learned that you should be careful when mixing codes of more than
one license. So the compatibility of licenses is the key.
Thank you for taking your precious time to answer my question.
Yuji
From: Bruno Haible
Subject: Re: Use of the secondary return value of compute-effective-method
Date:
Message-ID: <ceoegk$1jb$1@laposte.ilog.fr>
Yuji Minejima wrote:
> From MOP's description for COMPUTE-EFFECTIVE-METHOD,
> http://www.lisp.org/mop/dictionary.html#compute-effective-method
> > This generic function returns two values. The first is an effective
> > method, the second is a list of effective method options.
>
> For me, effective method options (actually the :arguments and the
> :generic-function options given in the long form of
> define-method-combination) seem to be of no or little use in this context.
> ...
> Could you tell me, who uses for what with this information?
As far as I can see, the :arguments option specifies a lambda list of
variables that are bound before the 1st value of compute-effective-method
is evaluated. As such, it is similar to the :arguments option of
define-method-combination.
The :generic-function option is indeed useless, since
compute-effective-method has been passed the generic function as argument,
and compute-effective-method could just use this generic function object
(quoted or not, doesn't matter, since it's self-evaluating) instead of
introducing a variable. But its existence increases consistency with the
define-method-combination macro.
Bruno