(I can't seem to subscribe to the Clisp mailing lists. Mail to
·········@clisp.cons.org" bounces---probably because the machine isn't
back up yet. My apologies if this is off-topic.)
I'm trying to get some code working in Clisp that uses CHANGE-CLASS
and UPDATE-INSTANCE-FOR-DIFFERENT-CLASS. Unfortunately, neither of
these generic functions are defined in the copy of Clisp that I have
installed on my machine (Clisp for Win32, 1999-07-22). Is there a
more recent version of Clisp available that supports CHANGE-CLASS; if
not, is this an "easy" fix that I could do myself (and where should I
start)?
--
"Applying computer technology is simply finding the right wrench to pound
in the correct screw." --.sig of Tim Wright, Sequent Computer Systems.
>>>>> "TB" == Tim Bradshaw <···@tfeb.org> writes:
TB> I thought that clisp had made a fairly intentional decision
TB> not to implement these kinds of bits of CLOS because they were
TB> considered either too hairy or not often enough used.
I can certainly understand that sentiment. I wish it were documented
in the README or something, though.
--
"Applying computer technology is simply finding the right wrench to pound
in the correct screw." --.sig of Tim Wright, Sequent Computer Systems.
From: Robert Monfera
Subject: Re: Where to post bug reports for Clisp?
Date:
Message-ID: <3848442E.49686396@fisec.com>
Matthew Economou wrote:
>
> >>>>> "TB" == Tim Bradshaw <···@tfeb.org> writes:
>
> TB> I thought that clisp had made a fairly intentional decision
> TB> not to implement these kinds of bits of CLOS because they were
> TB> considered either too hairy or not often enough used.
>
> I can certainly understand that sentiment.
This is surprising, given that the missing functions are part of Common
Lisp. If they were ignored, chances are little attention was payed to
CLOS as a whole in terms of completeness, optimization and debugging.
If anyone knows otherwise and was heavily using CLOS successfully with
CLISP, I'd like to hear about it.
Robert
From: Robert Monfera
Subject: Re: Where to post bug reports for Clisp?
Date:
Message-ID: <38487864.C046FB26@fisec.com>
Tim,
I wish you are right, and it is indeed possible that the implemented
part of CLOS is solid.
Your message actually carries the answer: if Bruno's ideas and
priorities determine what's implemented from CLOS, and there are
significant omissions and CLtL1 features, then it implies that CLISP
CLOS probably does not get a heavy use in general - otherwise people
would have contributed code that bring CLOS ANSI-compliant. One may
refer to PCL, but it's a non-native implementation.
Also, looking at the CLOS departures from ANSI, most of them 'only' seem
to require additional work, rather than to represent an underlying idea
on how things should be done properly (e.g., the example you point out).
These are the reasons why I _suspect_ CLISP CLOS is a second-class
citizen, as it is in other free implementations. This does not mean to
be an attack on Bruno, Roger or the CMUCL implementors, as I deeply
respect them for their achievement and contribution. I just don't like
the idea that one of the major things that make CL great is
disadvantaged, and people take it for granted - unlike for example
floating point performance, often considered of paramount importance.
Robert
Tim Bradshaw wrote:
>
> * Robert Monfera wrote:
> > This is surprising, given that the missing functions are part of Common
> > Lisp. If they were ignored, chances are little attention was payed to
> > CLOS as a whole in terms of completeness, optimization and debugging.
> > If anyone knows otherwise and was heavily using CLOS successfully with
> > CLISP, I'd like to hear about it.
>
> I don't think that follows. I think that CLISP's implementor reads
> this groups and can respond for himself, but my impression is that
> he's fully aware of the standard but has his own ideas on what should
> be there. So clisp may be idiosyncratic (an old example of this was
> its float contagion rules) and not-always conforming, but this doesn't
> imply that what is there does not work or has not been carefully
> implemented.
>
> --tim
* Robert Monfera wrote:
> Also, looking at the CLOS departures from ANSI, most of them 'only' seem
> to require additional work, rather than to represent an underlying idea
> on how things should be done properly (e.g., the example you point out).
Well, perhaps for some. But for the specific case that started this
thread -- changing classes of instances -- I think it's more than
`only' additional work. Being able to change the class of an object
has fundamental effects on how you represent it, and even then may be
really hard to get to work efficiently. From my own experience, in at
least 2 serious CLs, using CHANGE-CLASS is *really* bad in terms of
performance -- bad enough that I reimplemented my too-clever
class-changing trick some other way.
Steve Haflich has this notion of `things that exist to fill in a gap
in the functionality, but that you are not actually meant to use'
CHANGE-CLASS might be one of those, and it might be quite reasonable
to omit it.
--tim
>>>>> "TB" == Tim Bradshaw <···@tfeb.org> writes:
TB> From my own experience, in at least 2 serious CLs, using
TB> CHANGE-CLASS is *really* bad in terms of performance -- bad
TB> enough that I reimplemented my too-clever class-changing trick
TB> some other way.
I was afraid of that. I suspected that CHANGE-CLASS would create a
lot of garbage, and to find out that it also involves serious
computational overhead does not surprise me. C'est la vie.
My "too-clever class-changing trick" has to do with using the same
object to represent the parsing state AND the token being accumulated.
Methods on UPDATE-INSTANCE-FOR-DIFFERENT-CLASS handle token conversion
(e.g. from an integer to a symbol), while methods on a generic
function called ADD-CHARACTER-TO-TOKEN handle accumulating the token
and encode the state changes.
It's just too bad that Clisp doesn't have a feature-complete CLOS
implementation. It makes using/testing my code a little more
complicated (i.e. I have to upload the program to one of the UNIX
machines here and run it under CMUCL)---not really a show-stopper,
just inconvenient.
--
"Applying computer technology is simply finding the right wrench to pound
in the correct screw." --.sig of Tim Wright, Sequent Computer Systems.
From: Robert Monfera
Subject: Re: Where to post bug reports for Clisp?
Date:
Message-ID: <38487988.F41F8DF3@fisec.com>
Hi Matthew,
Please look at
http://clisp.cons.org/~haible/documentation/clisp/doc/impnotes.html
Sections 7 and 4. It is a great and clear collection of implementation
notes - too bad they discuss missing, rather than optimized CLOS
features :-)
Robert
Matthew Economou wrote:
>
> >>>>> "TB" == Tim Bradshaw <···@tfeb.org> writes:
>
> TB> I thought that clisp had made a fairly intentional decision
> TB> not to implement these kinds of bits of CLOS because they were
> TB> considered either too hairy or not often enough used.
>
> I can certainly understand that sentiment. I wish it were documented
> in the README or something, though.