I got a wild hair to port a Lisp program[1] written in Old Flavors (the
message-passing version) to CLOS. My goal is to do a complete port
without modifying the original source code. Rather, I'd like to create
the minimal necessary hosting environment for Flavors (and the graphics
stuff, which I'm ignoring for now).
The code makes use of only the most basic features of Flavors
(settable/gettable/initable instance vars, single inheritance) so a
straight port to CLOS seems doable with the appropriate macro-fu. For
example, defflavor is easily written to expand into the equivalent
defclass call.
At this point, I have two questions:
1. Is there an existing implementation of Old Flavors for CLOS? (Some
web hunting led me to the FMCS subsystem of the Babylon expert system
framework, and Michael Travers' CLOS*. The former is far too heavyweight
and doesn't appear to be implemented in terms of CLOS anyway. The latter
appears to be New Flavors in CLOS. Neither is the right answer for me.)
2. Is it really OK to use a keyword symbol as the function-name in a
defmethod form? E.g., (defmethod :foo ((self bar)) 'wtf-this-works?)
CLHS doesn't say no, and SBCL doesn't barf on such a thing, but I've
never done it before and it just looks funny. Of course, it sure helps
when porting keyword-named message-passing methods.
TIA,
Len
[1] Copycat, http://en.wikipedia.org/wiki/Copycat_%28software%29
In article <································@comcast.com>,
Len Charest <···········@usenet.len> wrote:
> I got a wild hair to port a Lisp program[1] written in Old Flavors (the
> message-passing version) to CLOS. My goal is to do a complete port
> without modifying the original source code. Rather, I'd like to create
> the minimal necessary hosting environment for Flavors (and the graphics
> stuff, which I'm ignoring for now).
>
> The code makes use of only the most basic features of Flavors
> (settable/gettable/initable instance vars, single inheritance) so a
> straight port to CLOS seems doable with the appropriate macro-fu. For
> example, defflavor is easily written to expand into the equivalent
> defclass call.
Franz has a version of Flavors:
http://www.franz.com/support/documentation/8.0/doc/flavors.htm
If you have a Symbolics, you can convert Flavors code
to CLOS with an editor command - IIRC.
Some Flavors here:
http://pdp-10.trailing-edge.com/clisp/index.html
>
> At this point, I have two questions:
>
> 1. Is there an existing implementation of Old Flavors for CLOS? (Some
> web hunting led me to the FMCS subsystem of the Babylon expert system
> framework, and Michael Travers' CLOS*. The former is far too heavyweight
> and doesn't appear to be implemented in terms of CLOS anyway. The latter
> appears to be New Flavors in CLOS. Neither is the right answer for me.)
>
> 2. Is it really OK to use a keyword symbol as the function-name in a
> defmethod form? E.g., (defmethod :foo ((self bar)) 'wtf-this-works?)
> CLHS doesn't say no, and SBCL doesn't barf on such a thing, but I've
> never done it before and it just looks funny. Of course, it sure helps
> when porting keyword-named message-passing methods.
>
> TIA,
> Len
>
> [1] Copycat, http://en.wikipedia.org/wiki/Copycat_%28software%29
Rainer Joswig wrote:
> Franz has a version of Flavors:
> http://www.franz.com/support/documentation/8.0/doc/flavors.htm
I happen to be he author of this code. That was during the spring of
1985...
>> 1. Is there an existing implementation of Old Flavors for CLOS?
I remember that it has been done, but I cannot remember details nor
who might have done it.
>> 2. Is it really OK to use a keyword symbol as the function-name in a
>> defmethod form? ... it sure helps
>> when porting keyword-named message-passing methods.
It does not violate the ANS, but it is obviously a bad idea (at least
in any new code). The purpose of packages is to prevent name
collisions, but since keywords are always globally available (since
they are effectively always coded with an explicit package prefix)
it is going against the intended design to make any bindings at all
upon keywords. Not functions, not block names, not catch tags, not
restarts, nor any other of CL's various namespaces.
IIRC some previous solutions for this problem put the keyword as an
eql specializer on the first arg, and the class on the second arg:
(deffmethod send ((message (eql :explode)) (object torpedo)) ...)
This isn't efficient, since discrimination on eql specializers is not
as efficient as on class specializers, but applications written with old
flavors were written for processors a couple orders of magnitude slower
than what we have today, so it might not matter.