Hi, out there!
I am working with CLOS and defined some classes
and methods. Now I want to call a particular one.
Let say:
(defclass aa ()())
(defclass bb (aa)())
* (defmethod ff ((aa aa)) ...)
(defmethod ff ((bb bb)) ...)
How do I call the method with the star * from
inside ff say of a class cc -> bb -> aa or from
outside ff at all?
Thanks!
--
Andreas Menke
·······@bln.de
> I am working with CLOS and defined some classes
> and methods. Now I want to call a particular one.
> (defclass aa ()())
> (defclass bb (aa)())
> * (defmethod ff ((aa aa)) ...)
> (defmethod ff ((bb bb)) ...)
> How do I call the method with the star * from
> inside ff say of a class cc -> bb -> aa or from
> outside ff at all?
What I assume you want is not (ff cc), but (ff->aa cc).
Methods in CLOS are called when they are applicable to its arguments,
unlike C++ as I understand which allows you to call them directly.
(which hard-codes inheritance into code rather than just in the classes)
To get the same effect in CLOS, you should define those methods
you want to call directly as functions,
and then call the function in the real method.
Then you can call the function from anywhere:
(defun ff->aa (aa) ...)
(defmethod ff ((aa aa))
(ff->aa aa)) ;; method code is just a call to the AA function
(defun hack-ff (cc)
;; (ff cc) // don't call ff method for class cc, since it breaks something
(ff->aa cc) ;; hack a call to the ff->aa method on cc
)
Another related mechanism is #'call-next-method, which invokes
the next-most-specific primary method within a primary method.
So in the ff method for class cc, can call (in the case cc->bb->aa)
would call the method for bb
(defmethod ff ((cc cc))
(if (skip-cc-stuff)
(call-next-method) ;; invoke inherited (in this case ff->bb)
..))
Hope this helps and wasn't too confusing..
-Kelly Murray ···@franz.com
Lisp for the 00's: http://charlotte.franz.com/silkos
From: Andreas Menke
Subject: Re: CLOS: How to call a method?
Date:
Message-ID: <35422623.44801CE8@bln.de>
Kelly Murray wrote:
> What I assume you want is not (ff cc), but (ff->aa cc).
> Methods in CLOS are called when they are applicable to its arguments,
> unlike C++ as I understand which allows you to call them directly.
> (which hard-codes inheritance into code rather than just in the classes)
>
> To get the same effect in CLOS, you should define those methods
> you want to call directly as functions,
> and then call the function in the real method.
> Then you can call the function from anywhere:
>
> (defun ff->aa (aa) ...)
> (defmethod ff ((aa aa))
> (ff->aa aa)) ;; method code is just a call to the AA function
>
> (defun hack-ff (cc)
> ;; (ff cc) // don't call ff method for class cc, since it breaks something
> (ff->aa cc) ;; hack a call to the ff->aa method on cc
> )
>
> Another related mechanism is #'call-next-method, which invokes
> the next-most-specific primary method within a primary method.
> So in the ff method for class cc, can call (in the case cc->bb->aa)
> would call the method for bb
>
> (defmethod ff ((cc cc))
> (if (skip-cc-stuff)
> (call-next-method) ;; invoke inherited (in this case ff->bb)
> ..))
>
> Hope this helps and wasn't too confusing..
>
> -Kelly Murray ···@franz.com
> Lisp for the 00's: http://charlotte.franz.com/silkos
>
Thanks a lot for the answer.
Sure, if I have access to all function definitions
(and I have and done as you say) this way is quite
easy.
I had experimented with find-method but there is
(as I found) no portable way to call a method
directly. And define-method-combination only works
for *all* virtual methods of this name.
?There is no privacy concept in CLOS, but most of
the world of OOP says that this is a very
important feature of OOP?
--
Andreas Menke
·······@bln.de
In article <·················@bln.de>, Andreas Menke <·······@bln.de> wrote:
>?There is no privacy concept in CLOS, but most of
>the world of OOP says that this is a very
>important feature of OOP?
The philosophy of Lisp, in general, is to make as much functionality
available to the programmer as possible. Concepts like hiding are better
left to programming conventions. Thus, although we have functions like
SLOT-VALUE and EVAL, good programmers know that they should ordinarily be
avoided. Or consider the package system, which allows you to access
non-exported symbols using the :: notation, something that hardly any other
language with the notion of packages or modules would think of allowing.
Lisp gives you plenty of rope, you're expected to avoid hanging yourself.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Barry Margolin <······@bbnplanet.com> writes:
>
> In article <·················@bln.de>, Andreas Menke <·······@bln.de> wrote:
> >?There is no privacy concept in CLOS, but most of
> >the world of OOP says that this is a very
> >important feature of OOP?
>
> The philosophy of Lisp, in general, is to make as much functionality
> available to the programmer as possible. Concepts like hiding are better
> left to programming conventions. [...]
This is a point of view held by a number of people.
I'd like to distance myself from it.
I find it routinely frustrating that I don't have better facilities
for expressing my desire for what protocols to have open and what to
have closed.
During the transition from CLTL(84) to ANSI CL, there were a number
of competing proposals for object systems. Among them were proposals
that offered considerably greater public/private distinctions than
we presently offer. I personally had no vote at the time, and was mostly
an observer. But I felt bad that such short shrift was paid to those
with other ideas.
The irony is that in the process of making CL, we (the greater Maclisp
community, which ultimately became Common Lisp) were "at war" with the
Interlisp community. We exiled a community. Such barriers are inevitably
transitory and the price of re-integrating a lost segment of society is
often to let them make some tangible effect on what you had previously
kept them from. The price to the CL community of getting the Interlisp
community back "on board", in my opinion, was the loss of the Flavors
object-oriented system, which was the familiar way for the people in the
then-CL community to do things. The Interlisp community arrived with
something called LOOPS which greatly affected the way people looked at things
(and for the better, I might add, though I'm not sure it was universally
perceived as better at the time). So LOOPS became CLOS and was accepted
into CL, displacing Flavors. But in the process, it too displaced a
community--the community of static programmers who had come to the door
at about the same time. I seem to recall a proposal by Russ Atkinson
and others, originally of the CLU community, which had a great deal more
to say about public/private matters and which we discarded. One day,
I suspect, we shall make our piece with them and again it will cost us
more than it would have had we listened then. At the time, it was just
a few changes. But by turning them away, their community diverges
and competes. And to reaccept them later means reintegrating whatever
they have done in the meantime. Perhap Dylan is one such way back.
Some see it as a Lisp, some don't ... perhaps the reason they don't
is they don't realize the enormity of the price that must be paid
today to get back what we lost then.
Then again, this is just all my personal recollection. And maybe others
will deny that this is how things happen at all. Or that there is ever a
price to be paid for locking people out.
Personally, I wish someone would have spent more time trying to integrate
the public/private distinctions in the package system with the
public/private distinctions in the object system. Again, C++ seems to
have at least tried, though their constraints were different so the result
is not immediately usable. It saddens me that classes can't have exported
interfaces that other classes can :use or :import-from. It would be nice
if one learned some general concepts about export/import and then applied
those concepts equally to various situations like packages and classes in
order to mix them.
Yes, Lisp has a tradition of making functionality available and leaving
hiding to programming conventions, as Barry says. But Lisp ALSO has a
tradition of making explicit what other languages do not. And it is not
beyond reason that the language would provide mechanisms for stating
those proggramming conventions in the form of machine-interpretable and
machine-enforceable abstractions such as public/private, import/export.
By the way, again just for the record, it was a major error that in
the process of moving from Flavors to CLOS, DEFUN-IN-FLAVOR was lost.
This Flavors function is the true cousin of the member function in C++
terms. Its important purpose was to be able to be mapped without
doing (mapcar #'foo (circular-list dispatch-instance) real-args).
By being closed over the instance, just (mapcar #'foo real-args) was
enough. Though maybe just providing a generalized currying operator would
be enough...
Oh well. Enough for now.
Kent M Pitman wrote:
>
> Barry Margolin <······@bbnplanet.com> writes:
> > The philosophy of Lisp, in general, is to make as much functionality
> > available to the programmer as possible. Concepts like hiding are better
> > left to programming conventions. [...]
>
> This is a point of view held by a number of people.
>
> I'd like to distance myself from it.
>
> I find it routinely frustrating that I don't have better facilities
> for expressing my desire for what protocols to have open and what to
> have closed. [...]
Very interesting comments, Kent.
Perhaps we could think about how it might be possible to integrate
hiding features into CLOS in an upward-compatible way, so that people
would not be forced to use them.
One very simple thought about that would be to decree that violations of
hiding would result in compiler warnings, but not errors -- the compiler
would still compile the program.
My own CLOS experience is still very limited, so I can't get much more
specific than that, but maybe this is as good a time & place as any to
start a brainstorming session.
> Then again, this is just all my personal recollection. And maybe others
> will deny that this is how things happen at all. Or that there is ever a
> price to be paid for locking people out.
Or perhaps will simply point out that no design satisfies all goals, and
"locking people out" is generally the price that must be paid in order
to get a decision made in finite time.
But one of the wonderful things about Lisp is the way it encourages
continued evolution. Onward to CLtL3... :-)
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
"Scott L. Burson" <·····@ricoqchet.net> writes:
> Perhaps we could think about how it might be possible to integrate
> hiding features into CLOS in an upward-compatible way, so that people
> would not be forced to use them.
Think away... :-)
> One very simple thought about that would be to decree that violations of
> hiding would result in compiler warnings, but not errors -- the compiler
> would still compile the program.
I think it would be more complex than that, but it's hard to say. It
depends on the specifics, and you might want to propose some. An example
specific that we didn't do that I personally wish we had was to not
have "slot merging" except where we exported something. Otherwise,
abstractions clobber each other when they choose overlapping slot names
for incompatible purposes. Mostly we get around that by creating package
partitions, but in some cases that forces more package divisions than
might be needed if the object system were itself cleaner.
But given that slot merging can occur, it's hard to tell when a call to
slot-value is violating an abstraction since it's hard to tell when two
classes are sharing slots and when they're clobbering each other. :-)
Also, in some cases, slot-value may get compiled with little knowledge
of the object class and so the time to warn would be runtime, not compile
time, which I would find largely ineffective and tedious.
> My own CLOS experience is still very limited, so I can't get much more
> specific than that, but maybe this is as good a time & place as any to
> start a brainstorming session.
comp.lang.lisp is a fine time and place for brainstorming sessions generally.
Sometimes they may go somewhere, sometimes not. But even where it goes
nowhere, we may learn things.
> > Then again, this is just all my personal recollection. And maybe others
> > will deny that this is how things happen at all. Or that there is ever a
> > price to be paid for locking people out.
>
> Or perhaps will simply point out that no design satisfies all goals, and
> "locking people out" is generally the price that must be paid in order
> to get a decision made in finite time.
A scary, but insightful thought, concisely made. Thanks!
> But one of the wonderful things about Lisp is the way it encourages
> continued evolution. Onward to CLtL3... :-)
Uh, ANSI CL 1999 perhaps? Formally, i.e. as a committee thing, CLTL2
never happened. Its presence and presentation created enormous
confusion in the marketplace, and confusion I personally hope never to
see repeated.
Only CLTL and ANSI CL were committee outputs.
CLTL2 was just a private work of Steele.
See CLTL2, last paragraph of page xii in the second edition preface,
continuing onto page xii for more details on this.
>>>>> "Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> "Scott L. Burson" <·····@ricoqchet.net> writes:
>> One very simple thought about that would be to decree that
>> violations of hiding would result in compiler warnings, but not
>> errors -- the compiler would still compile the program.
Kent> I think it would be more complex than that, but it's hard to
Kent> say. It depends on the specifics, and you might want to
Kent> propose some. An example specific that we didn't do that I
Kent> personally wish we had was to not have "slot merging" except
Kent> where we exported something. Otherwise, abstractions clobber
Kent> each other when they choose overlapping slot names for
Kent> incompatible purposes. Mostly we get around that by creating
Kent> package partitions, but in some cases that forces more package
Kent> divisions than might be needed if the object system were itself
Kent> cleaner.
Actually wouldn't something like the following work?
(defclass a ()
((#:a :initarg :a :accessor generic-a)
(public-b :initarg :b)))
That is, we could use uninterned symbols for slot-names that we don't
care about. This makes it impossible to use slot-value (for accessing
those slots, I mean) but I think that's generally a "good thing",
right?
As I don't have much experience with CLOS and its common idioms (its
pragmatics), I don't know whether this is acceptable.
--
Joao Cachopo * Homepage: http://www.gia.ist.utl.pt/~jcachopo
*** Murphy was an optimist ***
In article <···············@world.std.com> Kent M Pitman <······@world.std.com> writes:
I think it would be more complex than that, but it's hard to say. It
depends on the specifics, and you might want to propose some. An example
specific that we didn't do that I personally wish we had was to not
have "slot merging" except where we exported something. Otherwise,
abstractions clobber each other when they choose overlapping slot names
for incompatible purposes. Mostly we get around that by creating package
partitions, but in some cases that forces more package divisions than
might be needed if the object system were itself cleaner.
But given that slot merging can occur, it's hard to tell when a call to
slot-value is violating an abstraction since it's hard to tell when two
classes are sharing slots and when they're clobbering each other. :-)
Also, in some cases, slot-value may get compiled with little knowledge
of the object class and so the time to warn would be runtime, not compile
time, which I would find largely ineffective and tedious.
Hmmm, I assume you have read the AMOP book (even though you think it's not
yet at a usable stage). The reason I bring it up is that there is a
suggestion in there on how private slots might be implemented. Would that
serve as a good starting point for this discussion? (I would give more
details for everyone here that has not read the book, but I don't remember
most of the details of that particular exercise.)
Sunil
Kent M Pitman <······@world.std.com> writes:
> "Scott L. Burson" <·····@ricoqchet.net> writes:
>
> > One very simple thought about that would be to decree that violations of
> > hiding would result in compiler warnings, but not errors -- the compiler
> > would still compile the program.
That would not be acceptable. Lisp programmers often want to define
their own abstrasctions on topof Lisp, and it's very annoying if the
only way to do it turns out to be something that causes compiler
warnings. One of the reasons there was a PROCLAIM-LEXICAL cleanup
proposal (that would have introduced lexical global variables)
was that when Scheme systems were built in Common Lisp and
wanted to use Common Lisp nonlexical vars as globals, some
implementations produced compiler warnings.
> I think it would be more complex than that, but it's hard to say. It
> depends on the specifics, and you might want to propose some. An example
> specific that we didn't do that I personally wish we had was to not
> have "slot merging" except where we exported something.
Slot-merging is often nothing more than specifying a different
default value. Defstruct has a different syntax for saying things
about existing slots than for specifying new slots. This distinction
was removed in CLOS (it was in CommonLoops).
> Also, in some cases, slot-value may get compiled with little knowledge
> of the object class and so the time to warn would be runtime, not compile
> time, which I would find largely ineffective and tedious.
I think it was a bad idea to make slot-value the primitive...
-- jeff
Jeff Dalton wrote:
>
> Kent M Pitman <······@world.std.com> writes:
>
> > "Scott L. Burson" <·····@ricoqchet.net> writes:
> >
> > > One very simple thought about that would be to decree that violations of
> > > hiding would result in compiler warnings, but not errors -- the compiler
> > > would still compile the program.
>
> That would not be acceptable. Lisp programmers often want to define
> their own abstractions on top of Lisp, and it's very annoying if the
> only way to do it turns out to be something that causes compiler
> warnings.
Can we refrain, for the moment, from statements that express, or at
least seem to express, solidified positions (like "That would not be
acceptable")? It's said that the best way to do brainstorming is not to
permit negative comments at all during the initial idea-generation
period. I don't know that we need to go that far for this purpose -- I
don't really have a problem with expressions of valid *concerns* -- but
I do think the process will suffer if we dig into *positions* too
quickly.
It's not that I don't think your concern is valid: we do need to make
sure that such warnings can be circumvented when needed. But there may
very well turn out to be ways to do that. After all, at the moment,
CLOS has no way to express hiding concepts at all; and I already
suggested the desideratum that our proposal should be upward-compatible
-- I would add, in the strong sense that no currently correct CLOS
program should, under our proposal, generate any new compiler warnings.
Given that, it seems to me that your concern, while valid, is not
insurmountable.
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
"Scott L. Burson" <·····@ricoqchet.net> writes:
> Jeff Dalton wrote:
> > Kent M Pitman <······@world.std.com> writes:
> > > "Scott L. Burson" <·····@ricoqchet.net> writes:
> > > > One very simple thought about that would be to decree that
> > > > violations of hiding would result in compiler warnings, but
> > > > not errors -- the compiler would still compile the program.
> > That would not be acceptable. Lisp programmers often want to define
> > their own abstractions on top of Lisp, and it's very annoying if the
> > only way to do it turns out to be something that causes compiler
> > warnings.
> Can we refrain, for the moment, from statements that express, or at
> least seem to express, solidified positions (like "That would not be
> acceptable")?
My point was that there are reasons why, and empirical evidence that,
a significant number of Lisp programmers would object.
> It's said that the best way to do brainstorming is not to
> permit negative comments at all during the initial idea-generation
> period. I don't know that we need to go that far for this purpose -- I
> don't really have a problem with expressions of valid *concerns* -- but
> I do think the process will suffer if we dig into *positions* too
> quickly.
Well, a problem is that people tend to defend their beliefs,
rather than fairly consider contrary views. That can be
pointed out to all sides. However, it's sometimes a good
idea to raise problems sooner rather than later.
> It's not that I don't think your concern is valid: we do need to make
> sure that such warnings can be circumvented when needed. But there may
> very well turn out to be ways to do that.
I agree, but then we kind of have a different proposal. An separate
tool, a way to tell the compiler to check, or something else that's
portable and optional. (Re: portable -- it's a pain if the way
to ask for something is different in different implementations.)
> After all, at the moment,
> CLOS has no way to express hiding concepts at all; and I already
> suggested the desideratum that our proposal should be upward-compatible
> -- I would add, in the strong sense that no currently correct CLOS
> program should, under our proposal, generate any new compiler warnings.
The same issue may well arise for new features (depending, of course,
in what the new features are).
> Given that, it seems to me that your concern, while valid, is not
> insurmountable.
You're right, of course.
-- jeff
>I think it was a bad idea to make slot-value the primitive...
BTW, What do you suggest as an alternative?
In general, my opinion on hiding is that
a) it is a very important facility that has been neglected by Lisp
b) there isn't a great way to do it in CL
The CL package system could be used.
I think a simple change to the language that would NOT allow access to
internal symbols in a package using "::" would go a long way.
Then one could have libraries in which only exported symbols would
be accessible, and no internal information could be accessed.
The next problem is isolating access to not just symbols,
but the functionality they provide. If a symbol naming a class is exported,
then you wouldn't want to also export that symbol as a slot value,
or as a function.
Having hiding done per-class doesn't seem like the right granularity.
Typical useage in the past has been centered around at least
source-file granularity, where all the code in a file is part
of the library. I mean, if the source code is right there, there
isn't much case to be made saying you can't "get at" or change it.
I've been developing the concept of a "module" for Charlotte/SilkOS,
which is basically a CL package at this point.
-Kelly Murray ···@franz.com
Lisp for the 00's http://charlotte.franz.com/silkos
Kelly Murray <···@franz.com> writes:
> The CL package system could be used.
> I think a simple change to the language that would NOT allow access to
> internal symbols in a package using "::" would go a long way.
Internal symbols of what? Of the symbol-package of the containing class? Of the
current package? The self-same symbol might be exported in one package but
not in another. All trace of how I referenced it is gone by access time.
Suppose I referenced it as foo:x but you see it as bar::x -- does that make it
internal or external? The current package is not a good thing because I might
have legit reason to program in another package. And yet the symbol package
of the class might be bad because the symbol might be imported from elsewhere
and its home package might not be the package that was current at its point of
definition.
> Then one could have libraries in which only exported symbols would
> be accessible, and no internal information could be accessed.
> The next problem is isolating access to not just symbols,
> but the functionality they provide. If a symbol naming a class is exported,
> then you wouldn't want to also export that symbol as a slot value,
> or as a function.
>
> Having hiding done per-class doesn't seem like the right granularity.
Hmm. It does to me.
> Typical useage in the past has been centered around at least
> source-file granularity, where all the code in a file is part
> of the library.
What's the point of object-oriented programming if the boundary of
interest is textual and not object-oriented?? To me, file granularity
is what feels arbitrary.
> I mean, if the source code is right there, there
> isn't much case to be made saying you can't "get at" or change it.
This is a slippery slope argument. It can be extended easily to
directories and not just files. To things "in the editor". To things
"owned by the same user".
But more importantly, the whole point of programming paradigms is to
create artificial walls between parts of programs based on function rather
than code proximity. After all, in any tightly assembled application,
unrelated code will always appear next to unrelated code SOMEWHERE in
the image. Surely that can't be a good justification for allowing them
to violate each other's abstractions.
I quote (approximately) the late MIT Professor Bill Martin from a
computational linguistics class he taught: "The function of syntax in
a language isn't to allow one to say what's obvious, it's to allow one
to say what's NOT obvious." His point was that if we didn't have
syntax, we could just say "mouse cheese eat" and we would all know
what it meant. But by adding syntax, we can say things that are
interesting and surprising like "the cheese ate the mouse" not just
the obvious "the mouse at the cheese". Yes, it may SEEM obvious to
you that code in the same file should have access to other code in the
same file, but the whole point of syntax is to allow it not
to... because that may be what suits the need of the programmer on
some occasion.
Kelly Murray <···@franz.com> writes:
>In general, my opinion on hiding is that
> a) it is a very important facility that has been neglected by Lisp
> b) there isn't a great way to do it in CL
>The CL package system could be used.
>I think a simple change to the language that would NOT allow access to
>internal symbols in a package using "::" would go a long way.
>Then one could have libraries in which only exported symbols would
>be accessible, and no internal information could be accessed.
>The next problem is isolating access to not just symbols,
>but the functionality they provide. If a symbol naming a class is exported,
>then you wouldn't want to also export that symbol as a slot value,
>or as a function.
Yes, perhaps, but as long as the package itself is mutable, then the
choice of restricting the use of "::" seems rather arbitrary.
I may be missing something WRT packages, but it seems to me that if a
package isn't exporting a symbol, then you can go in and (EXPORT ...)
it. Source code or no.
Then you start digging into the whole introspection aspect of current
Lisp environments.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
······@netcom.com (Will Hartung) writes:
> I may be missing something WRT packages, but it seems to me that if a
> package isn't exporting a symbol, then you can go in and (EXPORT ...)
> it. Source code or no.
You are missing something. We're talking about the abstraction of
prevention, not about the science of it. It is by necessity
arbitrary. It's about being able to draw lines, now about where the
lines are drawn. It's about saying don't go past here, not about
preventing going past here. Heck, unless you have a very special file
system, it's possible to read the binary and edit it binary. You can't
realistically talk "forced" in any language until you can get the
image behind a firewall with the user on the other side. Even Java,
which purports to "force things" can't enforce it at the language
level; it's dependent on you picking a virtual machine that is fussy.
Certainly it is possible to build a JVM -- or if you insist it must
not then be named a JVM, then a machine that is like a JVM except
without security -- that is willing both to execute normal Java code
and give you access to so-called private structures freely. The point?
"Private" in programming languages is only EVER an abstraction, so don't
be surprised if it ends up being so here, too.
Kelly Murray <···@franz.com> writes:
> >I think it was a bad idea to make slot-value the primitive...
> BTW, What do you suggest as an alternative?
Functions. Slot-value seems to me a step backwards. It's like
expecting that (eval 'name) will work for local variables.
I also think it's a shame that "instance variables" were lost.
You have to explicitly arrange them using with-slots or with-
accessors, which is awkward.
And then I've found, after using Java, that it's nice if methods of
the same object can cell each other without explicitly passing the
object, though I'm not sure what the right Lispy syntax would be.
(It would also require a departure from the generic-function/multi-
method idea that no object is *the* object that "owns" the method,
so that there's no "this" or "self".)
> In general, my opinion on hiding is that
> a) it is a very important facility that has been neglected by Lisp
> b) there isn't a great way to do it in CL
Well, for some things, you can do this:
(let ( ... private variables ...)
(labels ( ... private functions ...)
... defuns for public functions ... ))
But, of course, that doesn't work for defstruct, defclass, ...
I think there are "Lispy" ways of hiding, such as sometimes come
up in discussions of Scheme.
> The CL package system could be used.
> I think a simple change to the language that would NOT allow access to
> internal symbols in a package using "::" would go a long way.
I might be inclined to agree with that, because "::" makes it
too easy. But you seem to have more in mind:
> Then one could have libraries in which only exported symbols would
> be accessible, and no internal information could be accessed.
So, for instance, presumably there'd be no (find-symbol name package-name).
And at that point, I find this desire to prevent access somewhat
hard to understand.
No one seems to think it's a terrible problem that debuggers can
get at things. (Maybe some people don't want debuggers to be able
to do it either, but such views don't seem to be a significant
factor in these discussions.)
So what we tend to get is a kind of ideological package: acces
restrictions + don't mix language and environment + something
about how programmers will break rules that aren't enforced by
the language.
In the end, I don't see why it's such a bad thing that I can
write some debugging tools myself, or why it should be my
problem that some other people will do bad things.
It's fine with me if some languages have all these rules, but
I'd also like to have some that don't.
> The next problem is isolating access to not just symbols,
> but the functionality they provide. If a symbol naming a class is exported,
> then you wouldn't want to also export that symbol as a slot value,
> or as a function.
> Having hiding done per-class doesn't seem like the right granularity.
> Typical useage in the past has been centered around at least
> source-file granularity, where all the code in a file is part
> of the library. I mean, if the source code is right there, there
> isn't much case to be made saying you can't "get at" or change it.
It depends on whether changing the source code will do anything.
For instance, I can change the source code to the C compiler I
use; but if I con't recompile it, relink, etc, I can't get around
any C rules.
> I've been developing the concept of a "module" for Charlotte/SilkOS,
> which is basically a CL package at this point.
Interesting. Maybe even ... cool.
-- jeff
(Geez, my first reply seems to have fallen into the bit bucket. Here's
another try...)
Kent M Pitman wrote:
>
> "Scott L. Burson" <·····@ricoqchet.net> writes:
>
> > One very simple thought about that would be to decree that violations of
> > hiding would result in compiler warnings, but not errors -- the compiler
> > would still compile the program.
>
> An example [of something]
> specific that we didn't do that I personally wish we had was to not
> have "slot merging" except where we exported something.
Good point.
It strikes me that in order to maintain upward compatibility, we'll have
to say that all slots and operations are public unless specifically
declared otherwise.
With that in mind, here's a naive suggestion. We introduce a
slot-option `:private' which means that the slot is to be visible only
to the class and its subclasses, and doesn't participate in slot
merging.
Hmm, what does "visible" mean? I guess the obvious suggestion is that a
call to `slot-value', in order to be able to access a private slot, has
to appear inside a `defmethod' one of whose specializers names the class
to which the slot is private, or one of its subclasses.
Do you suppose that could be made to work?
> Also, in some cases, slot-value may get compiled with little knowledge
> of the object class and so the time to warn would be runtime, not compile
> time, which I would find largely ineffective and tedious.
Hmm. I'm not sure what I think about this. On the one hand, what you
say seems difficult to disagree with. On the other, it seems that CLOS
has already committed itself to this path. That is, it's already the
case that one can write a call to `slot-value' such that the very
existence of the slot one is attempting to access may not be known until
runtime.
One thought would be that a private slot would simply appear not to
exist from the point of view of any call to `slot-value' that isn't
explicitly allowed to access it (by virtue of being in an appropriate
method). For the benefit of programs like inspectors, we could add a
`:private-to' argument to `slot-value' that would accept the class to
which the slot was private and thus permit access to the slot (we need
to know the class because the slot name isn't necessarily unique).
> > Or perhaps will simply point out that no design satisfies all goals, and
> > "locking people out" is generally the price that must be paid in order
> > to get a decision made in finite time.
>
> A scary, but insightful thought, concisely made. Thanks!
Well, it's possible I overstated the case; in particular, it's possible
that with a relatively small amount of effort, we can come up with an
elegant and useful design for hiding. If that's so, then one would be
tempted to conclude that the same thing could have been done prior to
the adoption of the standard, had the will to do so existed.
But certainly there are times when one is better off leaving something
out.
> > Onward to CLtL3... :-)
>
> Uh, ANSI CL 1999 perhaps?
Sure, yes, point taken.
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
In article <·················@ricoqchet.net>,
"Scott L. Burson" <·····@ricoqchet.net> writes:
> (Geez, my first reply seems to have fallen into the bit bucket. Here's
> another try...)
> Hmm, what does "visible" mean? I guess the obvious suggestion is that a
> call to `slot-value', in order to be able to access a private slot, has
> to appear inside a `defmethod' one of whose specializers names the class
> to which the slot is private, or one of its subclasses.
So then instead of just calling (slot-value foo
'private-slot), I'd have to do
(defmethod give-me-the-bleeping-value ((x bar))
(slot-value x 'private-slot))
first? Seems pretty easy to get around the hiding.
>> > Or perhaps will simply point out that no design satisfies all goals, and
>> > "locking people out" is generally the price that must be paid in order
>> > to get a decision made in finite time.
>>
>> A scary, but insightful thought, concisely made. Thanks!
>
> Well, it's possible I overstated the case; in particular, it's possible
> that with a relatively small amount of effort, we can come up with an
> elegant and useful design for hiding. If that's so, then one would be
> tempted to conclude that the same thing could have been done prior to
> the adoption of the standard, had the will to do so existed.
That doesn't necessarily follow. Maybe people's
attitudes and knowledge about what is and is not
important or doable have changed in the intervening
years.
I for one, think hiding is highly over rated. It's
based upon the assumption that we have to make
programming safe for moron programmers at the expense
of those who are wise enough not to muck with things
that they don't fully understand. Every time I've
been forced to use a C++ library written by others,
I've run into the case where the "designers" hide
some valuble piece of info. At that point, you either
have to reimplement the class with the info made
available or some gross hack like ((int *) foo)[5].
Mike McDonald
·······@mikemac.com
Mike McDonald wrote:
>
> So then instead of just calling (slot-value foo
> 'private-slot), I'd have to do
>
> (defmethod give-me-the-bleeping-value ((x bar))
> (slot-value x 'private-slot))
>
> first? Seems pretty easy to get around the hiding.
Point taken -- though I would counter that forcing the client to wrap
the access in a method is not entirely valueless, since it means that if
the implementor of `bar' were to delete slot `private-slot' or alter its
meaning, the client would at least have a convenient place in which to
emulate the old behavior, if that's possible.
Still, you're right -- if we're serious about enforcing this privacy,
we'll have to somehow circumscribe the collection of methods that are
permitted to be inside the abstraction. Not sure offhand how to do
that.
> > Well, it's possible I overstated the case; in particular, it's possible
> > that with a relatively small amount of effort, we can come up with an
> > elegant and useful design for hiding. If that's so, then one would be
> > tempted to conclude that the same thing could have been done prior to
> > the adoption of the standard, had the will to do so existed.
>
> That doesn't necessarily follow. Maybe people's
> attitudes and knowledge about what is and is not
> important or doable have changed in the intervening
> years.
Good point. Also, there can be reasonable shifts in priorities. I'd
venture to guess (not having actually been part of the process) that
during the first CL standardization effort, the thoughts of the CLOS
designers were largely preoccupied with MOP issues; and I think this was
probably appropriate. Now that the MOP is nailed down (so far as I
know, anyway), maybe we can look at other issues.
> I for one, think hiding is highly over rated.
I refer you to the message of Kent's that started this subthread (dated
Saturday, 13:58).
> Every time I've
> been forced to use a C++ library written by others,
> I've run into the case where the "designers" hide
> some valuable piece of info. At that point, you either
> have to reimplement the class with the info made
> available or some gross hack like ((int *) foo)[5].
Well, ideally the authors of the library can be persuaded to add the
feature you need to the public interface. This way, they're responsible
for maintaining it, and your code won't rot if they release a new
version the library. I don't know, though, how many library vendors are
enlightened enough to make it a policy to turn around requests like this
ASAP. Perhaps that should be something one asks about when selecting a
vendor.
If source code is available, one can make the change oneself, but then
it is necessary either to persuade the vendor to accept it or to merge
it into future upgrades one receives.
And then there's the gross hack approach, which I won't dignify by
discussing :-)
Hmm, gee, against the backdrop of those choices, the option of
permitting the client to extend the class with a method such as your
`give-me-the-bleeping-value' seems not without value. At least the
access is done by name rather than by word offset (!), and as I said
above, is forced to be encapsulated.
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
In article <·················@ricoqchet.net>,
"Scott L. Burson" <·····@ricoqchet.net> writes:
> And then there's the gross hack approach, which I won't dignify by
> discussing :-)
>
> Hmm, gee, against the backdrop of those choices, the option of
> permitting the client to extend the class with a method such as your
> `give-me-the-bleeping-value' seems not without value. At least the
> access is done by name rather than by word offset (!), and as I said
> above, is forced to be encapsulated.
>
> -- Scott
But how is the `give-me-the-bleeping-value' approach
any different than what exists today? Currently, if the
"designer" doesn't define accessors for the "private"
slots and I think I need them for some reason, I'd do
EXACTLY the same thing. To me, what accessors are or
are not defined gives the same info about the
"designer's" intent as labeling something "private".
Mike McDonald
·······@mikemac.com
Kent M Pitman <······@world.std.com> writes:
> Barry Margolin <······@bbnplanet.com> writes:
> > The philosophy of Lisp, in general, is to make as much functionality
> > available to the programmer as possible. Concepts like hiding are better
> > left to programming conventions. [...]
> This is a point of view held by a number of people.
> I'd like to distance myself from it.
> I find it routinely frustrating that I don't have better facilities
> for expressing my desire for what protocols to have open and what to
> have closed.
Do you really want to absolutely prevent programmers from accessing
functionality? Or do you merely want to be able to say what access is
intended and require that a special mechanism be used to get around
it? That latter seems reasonably consistent with the "Lisp philosophy"
to me.
(You later talk of "machine-enforceable abstractions", but that
doesn't quite say whether there's a way around them or not.)
Anyway, the "Lisp philosophy" has a couple of aspects. One is that the
primitives are available to the programmer. (Common Lisp sometimes
gets too far from this, IMHO. I find it annoying that in Common Lisp
a number of things that "you know have to be there" are hidden.)
Another aspect is the contrast with "police state" and "bondage
and discipline" languages which aim to prevent programmers from
doing "bad" things. I think that the basic point was put very
well by one of the Setl people: some languages try to make it
difficult to write bad programs, other try to make it easier
to write good programs.
The language features that stop programmers from doing "bad"
things often stop them from doing perfectly reasonable things
as well. And who gets to decide? Why can't I, as a programmer,
decide for myself whether I should do something or not?
> During the transition from CLTL(84) to ANSI CL, there were a number
> of competing proposals for object systems. Among them were proposals
> that offered considerably greater public/private distinctions than
> we presently offer. I personally had no vote at the time, and was mostly
> an observer. But I felt bad that such short shrift was paid to those
> with other ideas.
I think the proposal (from, I think, HP) that emphasised encapsulation
failed to be as nice on other ways as the competition; but politics,
or something like that, may also have been a factor.
> The price to the CL community of getting the Interlisp
> community back "on board", in my opinion, was the loss of the Flavors
> object-oriented system, which was the familiar way for the people in the
> then-CL community to do things.
I am not convinced. It was my impression that a number of
(non-Interlisp) people were not completely happy with Flavors.
(Indeed, there seemed to be a number of divergences withing the
"greater Maclisp commuinity", sometimes along Lisp machine /
non-LM lines.)
> ... So LOOPS became CLOS and was accepted into CL, displacing Flavors.
Surely that's oversimplified. For instance, CLOS has features from
New Falvors that were not LOOPS, and there are things from LOOPS that
are not in clos.
> But in the process, it too displaced a
> community--the community of static programmers who had come to the door
> at about the same time.
I can sort of see your point here, but I don't see how one language
can make everyone happy.
> ... But by turning them away, their community diverges
> and competes. And to reaccept them later means reintegrating whatever
> they have done in the meantime. Perhap Dylan is one such way back.
> Some see it as a Lisp, some don't ... perhaps the reason they don't
> is they don't realize the enormity of the price that must be paid
> today to get back what we lost then.
What is it that requires this enormous price? I can't quite
see what you have in mind here.
> Personally, I wish someone would have spent more time trying to integrate
> the public/private distinctions in the package system with the
> public/private distinctions in the object system. [...]
> It saddens me that classes can't have exported
> interfaces that other classes can :use or :import-from. It would be nice
> if one learned some general concepts about export/import and then applied
> those concepts equally to various situations like packages and classes in
> order to mix them.
What do you think of the Java approach?
-- jeff
Jeff Dalton <····@gairsay.aiai.ed.ac.uk> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Barry Margolin <······@bbnplanet.com> writes:
>
> > > The philosophy of Lisp, in general, is to make as much functionality
> > > available to the programmer as possible. Concepts like hiding are better
> > > left to programming conventions. [...]
>
> > This is a point of view held by a number of people.
>
> > I'd like to distance myself from it.
>
> > I find it routinely frustrating that I don't have better facilities
> > for expressing my desire for what protocols to have open and what to
> > have closed.
>
> Do you really want to absolutely prevent programmers from accessing
> functionality? Or do you merely want to be able to say what access is
> intended and require that a special mechanism be used to get around
> it? That latter seems reasonably consistent with the "Lisp philosophy"
> to me.
Well, this is a bit "of unstoppable force meets impenetrable barrier"
but yes, I want to prevent the access to functionality except by
documented means. I have been in commercial situations (in past lives
at other companies) where allowing customers access to an undocumented
system would seem "expedient" but came at the cost that we could never
change any aspect of the system because they never told us what they were
using. Finally we decided on the following policy: "we'd offer them
proper interfaces if they'd just tell us what they wanted interfaces to".
That means we could change parts of the system we knew people were not
using because we KNEW it was impossible for them to get to the other parts.
Anything less and it's a mess. So I really mean yes absolutely.
Of course, that doesn't mean I want people who don't want to take such a
posture to be prevented from programming more openly--my point is that it
is always the program provider who should have the option of dictating
on what terms use of the program is offered. It's then up to the free
market to decide if that leads to a good or bad commercial situation, but
it's not up to the market to decide that people shall not do business in
certain ways because presupposing that certain patterns are good and
others are bad in the absence of context amounts to biasing the market
and making it not free.
> (You later talk of "machine-enforceable abstractions", but that
> doesn't quite say whether there's a way around them or not.)
>
> Anyway, the "Lisp philosophy" has a couple of aspects. One is that the
> primitives are available to the programmer. (Common Lisp sometimes
> gets too far from this, IMHO. I find it annoying that in Common Lisp
> a number of things that "you know have to be there" are hidden.)
There's that word primitives again.
Yes, sometimes that's annoying. But it's for the market to sort that out.
There may be good reasons for them not to be advertised. Perhaps the
protocol for using them is in flux, and exposing the interface would
keep a new implementation from being installed. Look at the Lisp Machines
to see the effect of this. Three window systems because you can't
get people not to use the stuff "they know is there". Sheets. Dynamic
Windows. CLIM. Ditto class systems: flavors, CLOS. Ditto Lisp dialects:
Zetalisp, SCL, and ANSI CL. After a while, you start to see a cost in
terms of "deadweight old widgets" for letting people develop dependencies
on quite literally EVERYTHING.
> Another aspect is the contrast with "police state" and "bondage
> and discipline" languages which aim to prevent programmers from
> doing "bad" things. I think that the basic point was put very
> well by one of the Setl people: some languages try to make it
> difficult to write bad programs, other try to make it easier
> to write good programs.
Market again. Those are charged words. Some people like order and
some like freedom. Some call order bondage, some call freedom chaos.
Some talk about policies and practices as good things that make
life preditable, some see it as preventing creativity. It depends
on who's buying as to which programming system is best--if you're a
team of people who tend to write bad programs, the thing that makes
it hard to write bad programs may be best. Wanna make a wager about
whether most programming teams contain groups of people who mostly
write good or bad programs? ;-)
> The language features that stop programmers from doing "bad"
> things often stop them from doing perfectly reasonable things
> as well. And who gets to decide? Why can't I, as a programmer,
> decide for myself whether I should do something or not?
No reason. But why can't I as programmer decide for MYself whether
I should do something (i.e., inhibit you :-) or not. Back to
the paradox I opened with.
- - - - -
> > The price to the CL community of getting the Interlisp
> > community back "on board", in my opinion, was the loss of the Flavors
> > object-oriented system, which was the familiar way for the people in the
> > then-CL community to do things.
>
> I am not convinced. It was my impression that a number of
> (non-Interlisp) people were not completely happy with Flavors.
>
> (Indeed, there seemed to be a number of divergences withing the
> "greater Maclisp commuinity", sometimes along Lisp machine /
> non-LM lines.)
>
> > ... So LOOPS became CLOS and was accepted into CL, displacing Flavors.
>
> Surely that's oversimplified. For instance, CLOS has features from
> New Falvors that were not LOOPS, and there are things from LOOPS that
> are not in clos.
Tell me a grand truth that can be had without oversimplifying. The
whole point of oversimplifying is to offer insight. To properly
express what happened, one would have to watch a videotape of it,
blow by blow. This is why people with photographic recall are not
always good at passing tests that involve reasoning. The facts of
what happened must be possible to boil down.
Nor am I saying this is the only possible view on what happened. It's
just one person's observation, take it for what it's worth. You're
welcome to oversimplify in your own way and add to the body of wisdom
that came out of it. But if all you want to do is de-oversimplify me,
you'll end up only removing any insight I had to offer.
> > But in the process, it too displaced a
> > community--the community of static programmers who had come to the door
> > at about the same time.
>
> I can sort of see your point here, but I don't see how one language
> can make everyone happy.
>
> > ... But by turning them away, their community diverges
> > and competes. And to reaccept them later means reintegrating whatever
> > they have done in the meantime. Perhap Dylan is one such way back.
> > Some see it as a Lisp, some don't ... perhaps the reason they don't
> > is they don't realize the enormity of the price that must be paid
> > today to get back what we lost then.
>
> What is it that requires this enormous price? I can't quite
> see what you have in mind here.
When communities are shut out--pick your favorite real world country
where there is a division and run the thought experiment
yourself--people don't just in the end agree to be happy. Everyone
has to come back vindicated in the end. They can't just merge and
lose identity--they have to make the result their own or their people
will not accept the result. They must see compromise at least, and
sometimes active pain on the other side to believe they got a fair deal.
Some see Dylan as not very Lispy. It is infix. It lacks the READ/PRINT
thing. Its macros are very different. Its words for things are different.
It's more of a Lisp1. On and on with the differences. That's what those
who couldn't cope with Lisp as it was went off and did. If Lisp had
compromised earlier, it might have kept this division from forming.
But if Lisp wants this community back, it might have to give up a lot to
reattract those who have gotten used to this other community.
> > Personally, I wish someone would have spent more time trying to integrate
> > the public/private distinctions in the package system with the
> > public/private distinctions in the object system. [...]
> > It saddens me that classes can't have exported
> > interfaces that other classes can :use or :import-from. It would be nice
> > if one learned some general concepts about export/import and then applied
> > those concepts equally to various situations like packages and classes in
> > order to mix them.
>
> What do you think of the Java approach?
To be honest, I've not been tracking Java lately and don't have an
informed opinion. The second-hand discussions I overhear make it
sound like it went the way of MOO of creating a sort of "papered over"
kludge that largely hides the underlying weaknesses that single
inheritance brings and will work very practically for a while but perhaps
ultimately will fall of its own weight. But that's just a vague
feeling, since as I said, I haven't studied it thoroughly.
Part of the reason I haven't got a better opinion is that Java has
some much more basic problems with portability and interface
robustness such that a pile of the development and execution
environments I've tried have been real junk, and I have better things
to do than to try to debug them.
Still, never underestimate the power of a large installed base. Working
or not, a lot of people seem to have "committed to it" and I surely wonder
as much as the next soul what the end result of that is going to be.
Kent M Pitman wrote:
> Look at the Lisp Machines
> to see the effect of this. Three window systems because you can't
> get people not to use the stuff "they know is there". Sheets. Dynamic
> Windows. CLIM. Ditto class systems: flavors, CLOS. Ditto Lisp dialects:
> Zetalisp, SCL, and ANSI CL. After a while, you start to see a cost in
> terms of "deadweight old widgets" for letting people develop dependencies
> on quite literally EVERYTHING.
Was that really the problem? In all those cases, didn't the
*documented* interface change also? Maybe the task of porting from one
of those to the next was simpler for clients who used only the public
interface, but there was still work required.
Anyway, as a LispM user, I certainly did use undocumented interfaces,
but it never would have occurred to me to complain when they were
changed (as they were on occasion). Sometimes you just have to tell the
customer "sorry, but we told you this was subject to change".
> Some see Dylan as not very Lispy. It is infix. It lacks the READ/PRINT
> thing. Its macros are very different. Its words for things are different.
> It's more of a Lisp1. On and on with the differences. That's what those
> who couldn't cope with Lisp as it was went off and did. If Lisp had
> compromised earlier, it might have kept this division from forming.
> But if Lisp wants this community back, it might have to give up a lot to
> reattract those who have gotten used to this other community.
Well, I would paint that picture a little differently. The division
already existed -- a chasm, fairly, between Lispers and pretty much the
rest of the programming world. The design decisions that carried Dylan
away from Lisp were intended to bring it closer to everyone else. Thus
it's not so much a matter of getting a community back as of attracting
it in the first place.
It is ironic, though, in this connection, to recall that McCarthy never
intended S-expression notation to provide the primary way of interacting
with Lisp (er, I guess it was still IPL then). It caught on, I daresay,
because it was found convenient and expressive. Lispers can claim with
some justification that all those people in the infix world don't know
what they're missing; and it's entirely understandable that some would
be reluctant to give up their precious parentheses.
Furthermore, syntax, unfortunately, is a difficult issue to compromise
on, for obvious reasons.
The point of all this is just that I don't think there's any point in
lamenting the situation. Lisp is what it is for a bunch of good
reasons, and if all the C programmers in the world find it not to their
taste, well, that's life.
> To be honest, I've not been tracking Java lately and don't have an
> informed opinion. The second-hand discussions I overhear make it
> sound like it went the way of MOO of creating a sort of "papered over"
> kludge that largely hides the underlying weaknesses that single
> inheritance brings and will work very practically for a while but perhaps
> ultimately will fall of its own weight. But that's just a vague
> feeling, since as I said, I haven't studied it thoroughly.
I have written a small project in Java. I enjoyed it. Maybe I didn't
get to the point, in terms of size and complexity, where I would have
started stressing the inheritance model. But for what I did, I thought
it was a very nice language and a fine piece of work on the part of
Gosling et al.
Furthermore, it astonished me when I heard members of the Lisp community
dissing Java. The fact is, it's a lot closer to Lisp semantically than
to C or C++, despite the syntax. I think the Lisp world should be proud
of Java, quite frankly. It looks like it's well on the way to becoming
the first safe, garbage-collected language to achieve mainstream status.
I'm not saying it's perfect, or even that Dylan (which I'm less familiar
with) might not be better in a variety of ways. But it's a whole lot
better than the languages it seems likely to (at least partially)
replace, and IMO the reasons for that are rooted directly in the
influence Lisp had on it, via Gosling. In short, I think we should all
be quite happy about it. If you want to dis a language, Tcl is IMO a
much better choice :-)
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
"Scott L. Burson" <·····@ricoqchet.net> writes:
>
> Kent M Pitman wrote:
> > Look at the Lisp Machines
> > to see the effect of this. Three window systems because you can't
> > get people not to use the stuff "they know is there". Sheets. Dynamic
> > Windows. CLIM. Ditto class systems: flavors, CLOS. Ditto Lisp dialects:
> > Zetalisp, SCL, and ANSI CL. After a while, you start to see a cost in
> > terms of "deadweight old widgets" for letting people develop dependencies
> > on quite literally EVERYTHING.
>
> Was that really the problem? In all those cases, didn't the
> *documented* interface change also? Maybe the task of porting from one
> of those to the next was simpler for clients who used only the public
> interface, but there was still work required.
To the vendors trying to deliver a trim image? Absolutely.
> Anyway, as a LispM user, I certainly did use undocumented interfaces,
> but it never would have occurred to me to complain when they were
> changed (as they were on occasion). Sometimes you just have to tell the
> customer "sorry, but we told you this was subject to change".
It's true the LispM audience was very sophisticated, but even then,
there were complaints about MANY customers who had to pay 10's of
$1000's of dollars to receive new releases because of incompatible
changes. If you weren't among those complaining, don't think the problem
was not real.
And I used LispM's as the most clear illustration of the "compatibility
buildup problem", but it happens to lots of products--many of which don't
have a programmer audience as uniquely sophisticated as the LispM.
---
> Furthermore, it astonished me when I heard members of the Lisp community
> dissing Java. The fact is, it's a lot closer to Lisp semantically than
> to C or C++, despite the syntax. I think the Lisp world should be proud
> of Java, quite frankly. It looks like it's well on the way to becoming
> the first safe, garbage-collected language to achieve mainstream status.
Largely I have not been dissing Java. I'm happy it's out there. I
don't feel Lisp is threatened by it in the least. It seems to be
teaching people many useful concepts they'll need to know to use Lisp.
I think that's great for all concerned.
My remarks about the environments I've tried being junk were genuine and
not part of any smear campaign. I spent several frustrating days ordering
various commercial development environments that were ill documented and
crashed my mac, for example. Apple seems to be withholding support for 8.0
as a carrot for me to upgrade, but I don't have any special desire to
upgrade to 8.0, since I always find Apple's system upgrades to be enormously
disruptive; and I have a MacIvory on board that I worry won't work each
time I do... Symbolics not being around to fix it, that's a worry.
Java may indeed be on its way to win, but it's still new and the newness
is still costing it because the much touted ubiquity and uniformity of
interface are simply not yet here.
Also, its biggest problem is that it has made some marketing claims I
think it will never live up to. In particular, that it will "look the
same" in all environments. That's starting to get relaxed a bit, I
see, in that interfaces seem to be starting to pick min and max and
preferred sizes. I never did understand how it could "look the same"
with different resolution display devices, and they seem finally
starting to own up to that. Originally, the talk was of "exactly the
same".
Another and more subtle problem they're up against is verifiability.
You and I and the Java implementors presumably know that there are
limits on what can be verified. Sometimes programs do the wrong thing
and what is verified is NOT that. Of course, some claim that means
the verification still worked. But to the native establishment in the
real world, the point is subtle and the security models are going to
need some serious debugging -- and probably will still have troubles.
Personally, if I were them, I'd just back off the issue of verification
because it seems to me misleading at the product level. It's like
elevating a term like "typesafe arithmetic" to a marketing bullet of
"error-free arithmetic"... it isn't that it's a lie, it's just confusing
and ultimately maybe not the right thing to key on.
These aren't fatal points or a deathwish for Java by me by any means.
I suppose they're solvable. They're just my way of saying
"solvable" != "solved". Java has a ways to go in my personal book.
I suspect others' mileage varies depending on the quality of the
experiences they've had on the uneven terrain of the market. Given
the hype about how solid it is, I'm sure there's a tendancy to believe
that when it works ata ll, its' confirmation of the solidity. But
that's not the world's best way to do statistics. My remarks are not
statistical claims--they're just things that have affected and that
worry me... just one lone statistic for what it's worth.
> I'm not saying it's perfect, or even that Dylan (which I'm less familiar
> with) might not be better in a variety of ways. But it's a whole lot
> better than the languages it seems likely to (at least partially)
> replace, and IMO the reasons for that are rooted directly in the
> influence Lisp had on it, via Gosling. In short, I think we should all
> be quite happy about it. If you want to dis a language, Tcl is IMO a
> much better choice :-)
I guess you're talking to someone else--perhaps the crowd in general,
since that wasn't my intent at all.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> "Scott L. Burson" <·····@ricoqchet.net> writes:
>
>>
>> Kent M Pitman wrote:
>> > Look at the Lisp Machines
>> > to see the effect of this. Three window systems because you can't
>> > get people not to use the stuff "they know is there". Sheets. Dynamic
>> > Windows. CLIM. Ditto class systems: flavors, CLOS. Ditto Lisp dialects:
>> > Zetalisp, SCL, and ANSI CL. After a while, you start to see a cost in
>> > terms of "deadweight old widgets" for letting people develop dependencies
>> > on quite literally EVERYTHING.
>>
>> Was that really the problem? In all those cases, didn't the
>> *documented* interface change also? Maybe the task of porting from one
>> of those to the next was simpler for clients who used only the public
>> interface, but there was still work required.
>
> To the vendors trying to deliver a trim image? Absolutely.
As a Symbolics user of many a year, I never saw any
indication that Symbolics was trying to remove any of
those layers. Why should we users go thru the trouble
of converting our code to the new layer when Symbolics
wasn't leading the way with theirs? If you wanted to
indicate that Flavors, for example, wasn't going to be
supported in the future, rewrite Zemacs in CLOS. Yea,
I know. A LOT of work and a pain in the butt. Well,
converting our code was too. (And we actually did. We
started using Flavors and sheets and ended up using
CLOS and dynamic windows. (CLIM was just appearing at
the time we stopped.))
>> Anyway, as a LispM user, I certainly did use undocumented interfaces,
>> but it never would have occurred to me to complain when they were
>> changed (as they were on occasion). Sometimes you just have to tell the
>> customer "sorry, but we told you this was subject to change".
>
> It's true the LispM audience was very sophisticated, but even then,
> there were complaints about MANY customers who had to pay 10's of
> $1000's of dollars to receive new releases because of incompatible
> changes. If you weren't among those complaining, don't think the problem
> was not real.
Users ALWAYS complain. It's their job!
> And I used LispM's as the most clear illustration of the "compatibility
> buildup problem", but it happens to lots of products--many of which don't
> have a programmer audience as uniquely sophisticated as the LispM.
Nah, there's a better one around. You're probably
using it now. It's called Unix! Talk about build up!
(OK, it looks like you're a Mac user, but it applies
there too.)
> ---
>
>> Furthermore, it astonished me when I heard members of the Lisp community
>> dissing Java. The fact is, it's a lot closer to Lisp semantically than
>> to C or C++, despite the syntax. I think the Lisp world should be proud
>> of Java, quite frankly. It looks like it's well on the way to becoming
>> the first safe, garbage-collected language to achieve mainstream status.
>
> Largely I have not been dissing Java. I'm happy it's out there. I
> don't feel Lisp is threatened by it in the least. It seems to be
> teaching people many useful concepts they'll need to know to use Lisp.
> I think that's great for all concerned.
I think a lot of the "dissing" of Java from the
Lisp community is similar to the "Win95 = Mac89"
feelings.
> Java may indeed be on its way to win, but it's still new and the newness
> is still costing it because the much touted ubiquity and uniformity of
> interface are simply not yet here.
Will it ever be there? (Serious question!) There
are enormous interests that would prefer it not to be
uniform.
Mike McDonald
·······@mikemac.com
Kent M Pitman wrote:
>
> It's true the LispM audience was very sophisticated, but even then,
> there were complaints about MANY customers who had to pay 10's of
> $1000's of dollars to receive new releases because of incompatible
> changes. If you weren't among those complaining, don't think the problem
> was not real.
Okay, sorry, I didn't mean to trivialize the problem. I'm sure you had
some very difficult decisions to make.
> Largely I have not been dissing Java. [...]
>
> I guess you're talking to someone else--perhaps the crowd in general
It's true. I digressed. My remarks were not addressed to yours, just
something I had on my mind. Sorry for not being clearer.
And your points about the quality of the environments are well taken --
though less surprising when one considers how incredibly quickly some of
these things got built.
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
Kent M Pitman <······@world.std.com> writes:
Re: Java
> My remarks about the environments I've tried being junk were genuine and
> not part of any smear campaign. I spent several frustrating days ordering
> Also, its biggest problem is that it has made some marketing claims I
> think it will never live up to.
Yes. Like "write once, run everywhere" when the scheduling rules
for threads allow implementations to differ in crucial ways.
> In particular, that it will "look the
> same" in all environments. That's starting to get relaxed a bit, I
> see, in that interfaces seem to be starting to pick min and max and
> preferred sizes.
Just so. I was surprised that they'd not had both preferences,
since there were a number of places from which they could have
gotten the idea.
-- jd
"Scott L. Burson" <·····@ricoqchet.net> writes:
> It is ironic, though, in this connection, to recall that McCarthy never
> intended S-expression notation to provide the primary way of interacting
> with Lisp (er, I guess it was still IPL then).
Notations based on M-expressions (the non-S syntax) turned up
from time to time later on, for instance in McCarthy lecture
notes at least as recently as the 80s, and in Allen's Lisp
book (sorry I can't remember the title).
The Lisp 2 project had a more conventional syntax for the language,
though I think there was an S-expr syntax as well.
> It caught on, I daresay,
> because it was found convenient and expressive.
Yes, and (dare I say it?) some of us find it more readable too.
I find it interesting that there's so much resistance to that idea.
Many people seem unwilling to believe that anyone could really find
it more readable. It must be what they're "used to", or else they
put up with the syntax because of some other benefit (programming
environment, or macros, are the usual suggestions). I've even
seen students told that in a course teaching them Lisp!
> I have written a small project in Java. I enjoyed it. Maybe I didn't
> get to the point, in terms of size and complexity, where I would have
> started stressing the inheritance model.
The lack of proper multiple-inheritance (and of multi-methods) is
a problem, but (fortunately?) the C++ world has developed lots of
"patterns" that can often help.
> But for what I did, I thought
> it was a very nice language and a fine piece of work on the part of
> Gosling et al.
I think Java shows some signs of perhaps over-hasty work, and it's
needed some fixing in later versions. (Look at the various deprecated
features.)
Some things are annoyingly not-quite-right. For instance, "most"
things can be converted to strings, but there's no equivalent of Lisp
read for reading back the results. (I know about serialisation.)
The biggest of these, I think, is that the syntax could support
multi-arg dynamic dispatch, but static "overloading" resolution
is used instead. (It's a sign of something that many Java books
fail to make this clear, in ways that make it look like it never
occurred to the authors that anyone might expect multi-arg dispatch,
so that they don't realise that what they write could be read as
describing multi-arg actual-class-based lookup, rather than static,
declared-type resolution that's actually there.)
When you include the standard libraries, it's becoming huge.
Despite the "write once, run everywhere" aim, a counter-slogan,
"write once, debug everywhere" has (rightly) taken off. Some of
this "everywhere" problem will presumably be solved as implementations
mature (if the language stays still long enough), but the rules
for threads allow implementations to vary in ways that are bound to
result in bugs (including annoying, hard to debug, timing bugs)
when code is moved from one implementation to another.
But, taking all that (and some other things) into account, Java's not
too bad.
> Furthermore, it astonished me when I heard members of the Lisp community
> dissing Java. The fact is, it's a lot closer to Lisp semantically than
> to C or C++, despite the syntax. I think the Lisp world should be proud
> of Java, quite frankly. It looks like it's well on the way to becoming
> the first safe, garbage-collected language to achieve mainstream status.
I think Dylan's clearly a better language, but, yes, Java is
(surprisingly) Lisp-like.
The inner-class analogue of closures is actually usable, too,
though sometimes a bit verbose.
-- jeff
Jeff Dalton wrote:
> I think Java shows some signs of perhaps over-hasty work, and it's
> needed some fixing in later versions. (Look at the various deprecated
> features.)
Yes, it was done in a bit of a rush.
But compare C++, which has been around almost 15 years and is still
screwed up :-)
> the syntax could support
> multi-arg dynamic dispatch, but static "overloading" resolution
> is used instead.
Well, you make it sound like multi-arg dynamic dispatch could just be
"plugged in" to the existing language. I don't think it's that simple.
Okay, you *could* do dispatch that way and decide that methods
nevertheless run "inside" the object that is their first argument --
though you would still have to work out the implications for access to
private information. But I think you will agree that in a language
doing multi-arg dispatch, it is more natural not to have the methods run
inside any object at all, as in CLOS and Dylan. That is a much more
substantial redesign.
(In case it's not obvious -- by "running inside an object" I mean that
member variables and functions of the object can be accessed without
qualification.)
> (It's a sign of something that many Java books
> fail to make this clear, in ways that make it look like it never
> occurred to the authors that anyone might expect multi-arg dispatch,
> so that they don't realise that what they write could be read as
> describing multi-arg actual-class-based lookup, rather than static,
> declared-type resolution that's actually there.)
Well, yes, it's a sign that hardly anyone knows about CLOS or Dylan :-(
> When you include the standard libraries, it's becoming huge.
Is this a problem? I happen to like languages with lots of useful
functionality (e.g., Common Lisp). And the fact that this functionality
is organized into libraries (unlike CL) seems to me exactly right.
> Despite the "write once, run everywhere" aim, a counter-slogan,
> "write once, debug everywhere" has (rightly) taken off. Some of
> this "everywhere" problem will presumably be solved as implementations
> mature (if the language stays still long enough), but the rules
> for threads allow implementations to vary in ways that are bound to
> result in bugs (including annoying, hard to debug, timing bugs)
> when code is moved from one implementation to another.
Do you recall exactly what the problem is with the thread rules? I'm
curious.
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
In article <··············@gairsay.aiai.ed.ac.uk>,
Jeff Dalton <····@gairsay.aiai.ed.ac.uk> wrote:
>Despite the "write once, run everywhere" aim, a counter-slogan,
>"write once, debug everywhere" has (rightly) taken off.
The stupid thing about this slogan is that it has been the goal of almost
every high-level language. I guess it made sense to emphasize this since
the most popular competitor language, C, has some well-known system
dependencies in such basic areas as arithmetic (e.g. the result of
remainder involving negative numbers). What Java added was the ability to
ship byte code around and run it in a JVM within browsers or standalone
systems; this isn't new, either -- UCSD Pascal's Pcode worked this way, and
GNU Emacs Lisp byte codes are also portable (but there's no interpreter
other than GNU Emacs itself). The other thing Java brought to the table
was the standard UI library, but then Microsoft entered the picture and
announced that they wouldn't support the JFC.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Barry Margolin <······@bbnplanet.com> writes:
> In article <··············@gairsay.aiai.ed.ac.uk>,
> Jeff Dalton <····@gairsay.aiai.ed.ac.uk> wrote:
> >Despite the "write once, run everywhere" aim, a counter-slogan,
> >"write once, debug everywhere" has (rightly) taken off.
> The stupid thing about this slogan is that it has been the goal of almost
> every high-level language.
Yes! Just so.
Moreover, there's a kind of guarantee: that if you write conforming
code and use a conforming implementation, you will get behaviour
within a certain range. If you have a program such that it counts
as running correctly if the behaviour is in that range, you can write
it once and run it everywhere (everywhere where you use a conforming
implementation).
But this is rather complicated, and your program may behave
differently in different implementations.
The Java slogan makes it sound like it's offering something simpler.
I suspect a lot of people are assuming that if they get their program
to work in one Java implementation (ie, produce the expected
behaviour), then it will work in all others (modulo bugs in the
Java implementations, of course).
-- jeff
>Barry Margolin <······@bbnplanet.com> writes:
>
>> In article <··············@gairsay.aiai.ed.ac.uk>,
>> Jeff Dalton <····@gairsay.aiai.ed.ac.uk> wrote:
>
>> >Despite the "write once, run everywhere" aim, a counter-slogan,
>> >"write once, debug everywhere" has (rightly) taken off.
>
>> The stupid thing about this slogan is that it has been the goal of almost
>> every high-level language.
>
>Yes! Just so.
I think Sun really meant the slogan to be "Compile once, run everywhere",
but they changed it because non-programmer types think they know what
"write" means but none of them know what "compile" means. If you accept
this bit of revisionism, then the meaning of the slogan applied to Java
rather than most other languages becomes clearer. (Although of course there
have been other byte-compiled languages in the past.)
The other, less revisionist, interpretation of the slogan that gives it some
meaning is that Java includes a lot of API's that other languages don't,
making it possible to write more portable code. For instance, even though
C++ is (supposedly) portable, it doesn't include enough of a standard
library to make it possible to write interesting programs that run without
proprietary API calls on both Unix and Windows.
Certainly the slogan as it stands is fatuous, simplistic, and false, and so
inevitably leads to satire.
-- Harley
Harley Davis wrote:
>
> >Barry Margolin <······@bbnplanet.com> writes:
> >
> >> In article <··············@gairsay.aiai.ed.ac.uk>,
> >> Jeff Dalton <····@gairsay.aiai.ed.ac.uk> wrote:
> >
> >> >Despite the "write once, run everywhere" aim, a counter-slogan,
> >> >"write once, debug everywhere" has (rightly) taken off.
> >
> >> The stupid thing about this slogan is that it has been the goal of almost
> >> every high-level language.
> >
> >Yes! Just so.
>
> The other, less revisionist, interpretation of the slogan that gives it some
> meaning is that Java includes a lot of API's that other languages don't,
> making it possible to write more portable code.
Yes! Just so :-)
The keyword here is "*more* portable". Portability is a matter of
degree. Even if Java's portability isn't perfect, it's considerably
better than that of most languages people out there are using, even
before one considers the more-or-less standardized GUI API. I have no
problem with Sun using this as a selling point. As for the slogan being
"simplistic", well, *all* slogans are simplistic :-)
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
Kent M Pitman <······@world.std.com> writes:
> Jeff Dalton <····@gairsay.aiai.ed.ac.uk> writes:
> > Do you really want to absolutely prevent programmers from accessing
> > functionality? [...]
> Well, this is a bit "of unstoppable force meets impenetrable barrier"
> but yes, I want to prevent the access to functionality except by
> documented means.
Then don't use languages that don't let you do that.
> Of course, that doesn't mean I want people who don't want to take such a
> posture to be prevented from programming more openly--my point is that it
> is always the program provider who should have the option of dictating
> on what terms use of the program is offered.
So I, as a language designer, can't make my own choice?
Why not let the language designers design the languages they want to
design and let the market decide which ones "succeed"? The market seems
to be your answer everywhere else. :-)
> It's then up to the free
> market to decide if that leads to a good or bad commercial situation, but
> it's not up to the market to decide that people shall not do business in
> certain ways because presupposing that certain patterns are good and
> others are bad in the absence of context amounts to biasing the market
> and making it not free.
Languages that have "you can't do that" rules are doing exactly that.
Indeed, that's what "Police state" / "B&D" langauges do: presupposing
that certain patterns are good and others are bad in the absence of
context.
> > Anyway, the "Lisp philosophy" has a couple of aspects. One is that the
> > primitives are available to the programmer. (Common Lisp sometimes
> > gets too far from this, IMHO. I find it annoying that in Common Lisp
> > a number of things that "you know have to be there" are hidden.)
> Yes, sometimes that's annoying. But it's for the market to sort that out.
So the only way I can say what kind of language I prefer is to spend
money? I can't just *tell* someone? Sheesh!
(Elsewhere you're all for not excluding and for compromise. But here,
no. I can't say that about Common Lisp and expect any compromise or
not-exclusion. It's for the market to sort *that* out.)
> There may be good reasons for them not to be advertised. Perhaps the
> protocol for using them is in flux, and exposing the interface would
> keep a new implementation from being installed. Look at the Lisp Machines
> to see the effect of this. Three window systems because you can't
> get people not to use the stuff "they know is there".
Yes, you can't trust the programmers to do the right thing, so you
want the language to force them. I'm sure there are a number of
cases where that's a good idea. But those cases are not all cases.
> > Another aspect is the contrast with "police state" and "bondage
> > and discipline" languages which aim to prevent programmers from
> > doing "bad" things. I think that the basic point was put very
> > well by one of the Setl people: some languages try to make it
> > difficult to write bad programs, other try to make it easier
> > to write good programs.
>
> Market again. Those are charged words.
Of course. That's why they were used, historically. (I used them
to indicate what views I was talking about.)
Anyway, "market" is charged word. You're trying to make it seem
that if I disagree with you I'm wanting the market to be unfree,
or some other suspect thing.
And of course you ignore the other half of the paragraph.
Anyway, my view is that there's more than one good kind of programming
language, and that "Lisp philosophy" languages can be good languages.
This is not to say that *all* languages should be like that.
> > The language features that stop programmers from doing "bad"
> > things often stop them from doing perfectly reasonable things
> > as well. And who gets to decide? Why can't I, as a programmer,
> > decide for myself whether I should do something or not?
>
> No reason. But why can't I as programmer decide for MYself whether
> I should do something (i.e., inhibit you :-) or not.
In a sense, any language lets you do some things and not others.
Anyway, the idea that your range of free choice should include being
able to inhibit me sounds rather odd coming from such a fan of
markets. Don't your rights end where mine begin? Or is it markets
without rights that you think are such a good idea?
> - - - - -
> Tell me a grand truth that can be had without oversimplifying. The
> whole point of oversimplifying is to offer insight.
Not always. Note too that oversimplifying is *over*simplifying.
Flavors was widely used, but there was also fairly widespread
dissatisfaction with some aspects of Flavors. Many of the issues
were addressed by New Flavors. CLOS is, largely, a combination of
(features of) New Flavors and CommonLoops. CommonLoops was already
significantly different from LOOPS.
There is much more of an Interlisp-community influence and role
in CLOS than in the earlier parts of Common Lisp. But I do not think
it's right to say "LOOPS became CLOS and was accepted into CL,
displacing Flavors".
If you really disagree with my above "oversimplification" of CLOS
history (apart from what I've left out about Common Objects and its
concern with encapsulation, and about ObjectLisp), I'd like to know
why. I have an open mind about this (yes), because I know there's a
great deal about what people were saying and thinking in those days
that I don't know.
> > > ... But by turning them away, their community diverges
> > > and competes. And to reaccept them later means reintegrating whatever
> > > they have done in the meantime. Perhap Dylan is one such way back.
> > > Some see it as a Lisp, some don't ... perhaps the reason they don't
> > > is they don't realize the enormity of the price that must be paid
> > > today to get back what we lost then.
> > What is it that requires this enormous price? I can't quite
> > see what you have in mind here.
> When communities are shut out--pick your favorite real world country
> where there is a division and run the thought experiment
> yourself--people don't just in the end agree to be happy. Everyone
> has to come back vindicated in the end. They can't just merge and
> lose identity--they have to make the result their own or their people
> will not accept the result. They must see compromise at least, and
> sometimes active pain on the other side to believe they got a fair deal.
So people who have sufficiently different ideas about the programming
language they want to design can't just ... design different languages?
I happen to think it's good that the ML people, for example, designed
ML rather than trying not to "exclude" anyone.
(This is not to say that, in the Lisp world, the Interlisp people,
or Europeans, should have been excluded from the design of Common Lisp.
Politically, and no doubt in some other ways, that may well have been
a mistake. More could have been done to make CL more palatable
to those who prefer Scheme, as well.)
> Some see Dylan as not very Lispy. It is infix. It lacks the READ/PRINT
> thing. Its macros are very different. Its words for things are different.
> It's more of a Lisp1. On and on with the differences. That's what those
> who couldn't cope with Lisp as it was went off and did. If Lisp had
> compromised earlier, it might have kept this division from forming.
> But if Lisp wants this community back, it might have to give up a lot to
> reattract those who have gotten used to this other community.
If *Lisp* had compromised earlier? Lisp is pretty broad, you know,
and "even" Common Lisp makes some things opaque. You can prevent
access pretty easily by writing inside let and labels.
(Unfortunately, defclass and CLOS aren't "lexical" in the required
way.)
If we consider *Common* Lisp, though, I think some compromises would
have helped a great deal.
If we set syntax aside, Dylan is fairly close to certain "post-CL"
Lisps such as EuLisp. There was also a widespread dissatisfaction
with certain aspects of Common Lisp, such as how big implementations
(and Common Lisp) were, and how everything was in one big bag of
features, rather than being nicely divided into language and various
libraries.
Compromises in a Dylan-like direction could have been made, addressing
many of the same issues that Dylan aimed to address.
Later, some of the prominent Common Lispers went off to Dylan. Yes,
some of the Dylan folk were among the very people who could have
"compromised earlier". If they "couldn't cope with Lisp as it was",
they could have done something different earlier on.
> > > It saddens me that classes can't have exported
> > > interfaces that other classes can :use or :import-from. It would be nice
> > > if one learned some general concepts about export/import and then applied
> > > those concepts equally to various situations like packages and classes in
> > > order to mix them.
> > What do you think of the Java approach?
> To be honest, I've not been tracking Java lately and don't have an
> informed opinion. The second-hand discussions I overhear make it
> sound like it went the way of MOO of creating a sort of "papered over"
> kludge that largely hides the underlying weaknesses that single
> inheritance brings and will work very practically for a while but perhaps
> ultimately will fall of its own weight. But that's just a vague
> feeling, since as I said, I haven't studied it thoroughly.
Java has a number of problems, and it's use of "general concepts about
export/import" is not as elegant as it could be. But I think it does
a fairly good job in that area, for something that isn't too complex.
-- jd
Andreas Menke <·······@bln.de> writes:
>
> Hi, out there!
>
> I am working with CLOS and defined some classes
> and methods. Now I want to call a particular one.
Well, the correct answer for Common Lisp is that you don't do this in a
normally constructed program. In fact, there isn't any direct support
for this in the language. (Except via call-next-method)
The fundamental question you need to ask yourself is why it is that you
would want to do this in the first place. If it is a question of trying
to build a cascade of calls up an inheritance hierarchy, then
call-next-method is the appropriate way to do it.
> Let say:
> (defclass aa ()())
> (defclass bb (aa)())
> * (defmethod ff ((aa aa)) ...)
> (defmethod ff ((bb bb)) ...)
> How do I call the method with the star * from
> inside ff say of a class cc -> bb -> aa or from
> outside ff at all?
If you ever have a reason to want to skip the ff method on BB when
invoking it from an instance of CC, that is a sign that you have a
fundamental design problem in your code. In other words, if the method
FF on things of type CC should use the one from AA rather than BB, then
CC is not properly a (logical) subtype of BB, and therefore shouldn't be
placed there in your class hierarchy.
Perhaps if you tell us why you need this capability we can offer some
more specific advice about structuring your program in a CLOS-supported
way.
> Andreas Menke
> ·······@bln.de
>
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Andreas Menke
Subject: Re: CLOS: How to call a method?
Date:
Message-ID: <3545E083.7327A2D4@bln.de>
Thomas A. Russ wrote:
>
> Andreas Menke <·······@bln.de> writes:
>
> >
> > Hi, out there!
> >
> > I am working with CLOS and defined some classes
> > and methods. Now I want to call a particular one.
>
> Well, the correct answer for Common Lisp is that you don't do this in a
> normally constructed program. In fact, there isn't any direct support
> for this in the language. (Except via call-next-method)
>
> The fundamental question you need to ask yourself is why it is that you
> would want to do this in the first place. If it is a question of trying
> to build a cascade of calls up an inheritance hierarchy, then
> call-next-method is the appropriate way to do it.
>
> > Let say:
> > (defclass aa ()())
> > (defclass bb (aa)())
> > * (defmethod ff ((aa aa)) ...)
> > (defmethod ff ((bb bb)) ...)
>
> > How do I call the method with the star * from
> > inside ff say of a class cc -> bb -> aa or from
> > outside ff at all?
>
> If you ever have a reason to want to skip the ff method on BB when
> invoking it from an instance of CC, that is a sign that you have a
> fundamental design problem in your code. In other words, if the method
> FF on things of type CC should use the one from AA rather than BB, then
> CC is not properly a (logical) subtype of BB, and therefore shouldn't be
> placed there in your class hierarchy.
>
> Perhaps if you tell us why you need this capability we can offer some
> more specific advice about structuring your program in a CLOS-supported
> way.
>
> > Andreas Menke
> > ·······@bln.de
> >
>
> --
> Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
The concrete problem is (shortend for simplicity):
I have a class of 'justification' objects, that is that
instances of this class can justify for themselves in a given
context.
Now I subclassed it to a 'sundry' which pushes subclassing to
ordinary functions but default behaviour is to
call-next-method and I loose. (Pushing to functions is for
users benefit to have good default behaviour and not to write
own subclasses but particular functions instead.)
(defclass justification (...)(...)...)
(defmethod justify ((just justification)) ...)
(defclass sundry (justification) (
(action :accessor action :type function)
))
(defmethod justify ((sundry sundry))
(if (slot-boundp sundry 'action)
(funcall (action sundry) sundry)
(call-next-method sundry)))
Sure, there are many solutions depending on further context
information or not, what I mean is that there is a privacy I
do *not* want namely 'method privacy' (no portable way of
calling methods directly). My solution is that of Kelly Murray
<···@franz.com> so I defined:
(defmethod justify-just ((just justification)) ...)
(defmethod justify ((just justification))
(justify-just just))
But this is bad coding (in my opinion).
I think CLOS losses a general concept of privacy like the
package concept for globals.
--
Andreas Menke
·······@bln.de
In article <·················@bln.de>, Andreas Menke <·······@bln.de> wrote:
>Hi, out there!
>
>I am working with CLOS and defined some classes
>and methods. Now I want to call a particular one.
>Let say:
>(defclass aa ()())
>(defclass bb (aa)())
>* (defmethod ff ((aa aa)) ...)
>(defmethod ff ((bb bb)) ...)
>How do I call the method with the star * from
>inside ff say of a class cc -> bb -> aa or from
>outside ff at all?
>
>Thanks!
>
>--
>Andreas Menke
>·······@bln.de
>
How about using the meta-object protocol? It is not (yet) part of the
ANSI standard and therefore not portable, but e.g. using ACL 4.3 you
can do
(funcall (clos::method-function (find-method #'ff nil (list (find-class 'aa))))
(make-instance 'bb))
Bernhard
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
In article <·············@www.univie.ac.at> ········@korb.ai.univie.ac.at (Bernhard Pfahringer) writes:
In article <·················@bln.de>, Andreas Menke <·······@bln.de> wrote:
>Hi, out there!
>
>I am working with CLOS and defined some classes
>and methods. Now I want to call a particular one.
>Let say:
>(defclass aa ()())
>(defclass bb (aa)())
>* (defmethod ff ((aa aa)) ...)
>(defmethod ff ((bb bb)) ...)
>How do I call the method with the star * from
>inside ff say of a class cc -> bb -> aa or from
>outside ff at all?
>
>Thanks!
>
>--
>Andreas Menke
>·······@bln.de
>
How about using the meta-object protocol? It is not (yet) part of the
ANSI standard and therefore not portable, but e.g. using ACL 4.3 you
can do
(funcall (clos::method-function (find-method #'ff nil (list (find-class 'aa))))
(make-instance 'bb))
Bernhard
What if the method has a call to call-next-method?
Sunil