Common Lisp has CLOS, which is, I think, the single most complete
set of OO functionality in any language. If anybody can think of
any OO technique implemented anywhere that's not in CLOS, I'd like
to hear about it.
Has anybody gathered statistics on CLOS usage patterns? Are there
features that are seldom or never used? Are there features the use
of which, now that we have experience of them, usually indicates a
design mistake?
I know that some coders whom I truly respect say they've never
cared much about CLOS, but I also know teams of coders who regard
its frameworks and shared idiom as pivotal in getting pieces of
code developed by different people in different places for different
purposes to work together, and I'm inclined to believe them.
I have to 'fess up here that I don't use CLOS much; I use closures
mainly instead of more formal hierarchical objects (chalk it up to
my Scheme background and techniques established before I started
hacking CL at all). But I am now implementing and designing a
lisp dialect which I've recently decided I will release when it's
done, and I've been thinking about OO extensions.
Scheme doesn't standardize much beyond a small set of powerful
primitives, and as a result there are a thousand ways to do
common things like OO programming. Typically closures are used
as adhoc objects, but for those who want a more formal framework,
plenty of incompatible systems like Meroon and TinyCLOS abound.
Each of these isolates code written depending on it into separate
camps, making it hard to integrate with any code that uses a
different object system, or hard to understand when working
with code that uses a different object system, and IMNSHO
the inconsistencies caused by not having common idioms tend
to limit people's ability to "assemble" large systems out of
preexisting parts.
So even though I don't personally use OO much, I have to admit
that it seems to have value beyond "buzzwordiness," especially
for the development of interoperating libraries. Therefore, any
Lisp that's going to be viable (or around long enough to build
substantial libraries) has to specify a set of OO idioms so
that code written by different people in different places can
work in the same app with the same MOP, etc.
So that brings up the point: I'm wondering how the OO system has
affected Common Lisp development and developers; how important
it has been, whether people think anything about it could have
been done better differently, and whether any parts of it are
now widely regarded as mistakes?
Any help or input would be appreciated.
Bear
Ray Dillinger wrote:
> Has anybody gathered statistics on CLOS usage patterns? Are there
> features that are seldom or never used? Are there features the use
> of which, now that we have experience of them, usually indicates a
> design mistake?
no, no, and no.well, the CPL calculation has an obscure flaw. Go with
Dylan's.
> I have to 'fess up here that I don't use CLOS much; I use closures
> mainly instead of more formal hierarchical objects
No, GFs? I love GFs.
> Scheme doesn't standardize much beyond a small set of powerful
> primitives, ....
> the inconsistencies caused by not having common idioms tend
> to limit people's ability to "assemble" large systems out of
> preexisting parts.
yep. puts a pointless upper bound on what the community can accomplish.
>
> So that brings up the point: I'm wondering how the OO system has
> affected Common Lisp development and developers;
It's the only way to fly/
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
On Sun, 27 Mar 2005 05:53:29 GMT, Kenny Tilton wrote:
> Ray Dillinger wrote:
>> Has anybody gathered statistics on CLOS usage patterns? Are there
>> features that are seldom or never used? Are there features the use
>> of which, now that we have experience of them, usually indicates a
>> design mistake?
> no, no, and no.well, the CPL calculation has an obscure flaw. Go with
> Dylan's.
If you're starting from scratch, go with Python's instead (the "C3"
algorithm described in the Dylan paper, not the "Dylan" one)
FWIW: http://users.actrix.co.nz/mycroft/dylan.lisp
--
If that makes any sense to you, you have a big problem.
-- C. Durance, Computer Science 234
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley (http://public.xdi.org/=pf) wrote:
> ...the algorithm described in the Dylan paper, not the "Dylan" one
So Dylan does not use the algorithm described in the Dylan paper? I did
not know that. Fascinating. I just assumed the Dylan CPL calculation was
that described in the Dylan paper. Silly me. Thanks for straightening me
out on that. What algorithm does it use? Why did they write that paper?
Why didn't they use the algorithm described in the paper? Do you happen
to know the Dylan CPL calculation? Can you explain how it differs from
that in the Dylan paper? Thanks in advance.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
On Mon, 28 Mar 2005 03:31:47 GMT, Kenny Tilton wrote:
> Paul Foley (http://public.xdi.org/=pf) wrote:
>> ...the algorithm described in the Dylan paper, not the "Dylan" one
No I didn't. What I wrote was
the "C3" algorithm described in the Dylan paper, not the "Dylan" one
^^^^
That "C3" you clipped out is fairly important to the meaning!
> So Dylan does not use the algorithm described in the Dylan paper? I did
> not know that. Fascinating. I just assumed the Dylan CPL calculation was
> that described in the Dylan paper. Silly me. Thanks for straightening me
> out on that. What algorithm does it use? Why did they write that paper?
There are /two/ algorithms described in that paper (well, three,
actually, if you count the CLOS one). Dylan, appropriately enough,
uses the one they call "Dylan".
The other one, which the authors call "C3", is the one I'm suggesting
instead.
--
If that makes any sense to you, you have a big problem.
-- C. Durance, Computer Science 234
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Ray Dillinger <····@sonic.net> writes:
> Common Lisp has CLOS, which is, I think, the single
> most complete set of OO functionality in any language.
> If anybody can think of any OO technique implemented
> anywhere that's not in CLOS, I'd like to hear about it.
Here are a few thoughts off the top of my head.
1. Ability to define methods for built-in operations,
such as arithmetic (as in Dylan, Smalltalk, Dylan, C++, etc.)
Users might want to create new kinds of numeric data types.
There are related features/issues with other built-in types,
such as arrays and hash tables.
In Common Lisp, such built-in functions are not generic,
the main argument being a philosophical distrust of users
to extend the semantics of functions that were defined by
the core language. There are also efficiency issues.
2. Class protocol specifications such as required superclasses,
slots, initargs, and methods that must be defined somewhere;
non-instantiable (abstract) classes; sealing classes, etc.
3. Control over the implementation of objects.
Extensible language facilities for specifying the
layout (bits) of a slot value. Also, controlling the
memory (area, or even a wired address) where the object
will be allocated. These facilities are for foreign
interface types of things, and for and machine-level
programming in Lisp.
4. Default handler for undefined operations on the object;
this is essentially a hook method for "Undefined Function"
call errors. (This is useful in message-passing style,
and complements some MOP introspection features.)
5. The ability to define macros that are available
only within methods of a given class.
6. Runtime control over the class of the object to be
instantiated. (The object returned by MAKE-INSTANCE
depends on some logic in the requested class.
Flavors had a language (specified in the :MIXTURE
option of DEFFLAVOR) for statically programming
the dynamic composition of classes. To run it,
you pass keywords to MAKE-INSTANCE, and a new subclass
is defined (and instantiated) right then.
7. Not abot CLOS per se: Pathnames, Conditions, Hash Tables,
and Streams should be CLOS-based, standardized, and elaborated.
8. The MOP is not part of the ANSI standard.
I am not saying that everything above is necessarily desirable,
but it's a laundry-list of features that I've actually used in
other Lisp systems.
Much of what I've mentioned above can be implemented by
programming with the existing MOP. Some of it would
require changes and additions to Common Lisp.
I am also under the impression that there are some outstanding
semantic issues with multiple-inheritence class/method combination.
(But I don't think I've really run into the supposed problems
in that area, so someone else will have to comment.)
Christopher C. Stacy wrote:
> Ray Dillinger <····@sonic.net> writes:
>
>>Common Lisp has CLOS, which is, I think, the single
>>most complete set of OO functionality in any language.
>>If anybody can think of any OO technique implemented
>>anywhere that's not in CLOS, I'd like to hear about it.
> 5. The ability to define macros that are available
> only within methods of a given class.
What would this be useful for? Do you have an example?
Pascal
Pascal Costanza <··@p-cos.net> writes:
> Christopher C. Stacy wrote:
> > Ray Dillinger <····@sonic.net> writes:
> >
> >> Common Lisp has CLOS, which is, I think, the single most complete
> >> set of OO functionality in any language.
> >>If anybody can think of any OO technique implemented
> >>anywhere that's not in CLOS, I'd like to hear about it.
>
> > 5. The ability to define macros that are available only within
> > methods of a given class.
>
> What would this be useful for? Do you have an example?
I don't think I ever used it myeelf, but I found about 140 such
macro definitions occurring in in a lage system that looked at.
There was nothing remarkable about them.
If my description was not clear: it provides a way to define a macro
that cannot be invoked except by methods of some class. It documents
and prevents the macro from being accidently called from elsewhere.
Some of the usages I saw also took advantage of the fact that in Flavors,
methods (and these macros) can make free lexical references to the
instance variables (like an automatic WITH-SLOTS).
······@news.dtpq.com (Christopher C. Stacy) writes:
> If my description was not clear: it provides a way to define a macro
> that cannot be invoked except by methods of some class. It documents
> and prevents the macro from being accidently called from elsewhere.
Is this just an access check, or the scope of a binding: can the
same symbol name a different macro for methods of some other
class?
Kalle Olavi Niemitalo <···@iki.fi> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > If my description was not clear: it provides a way to define a macro
> > that cannot be invoked except by methods of some class. It documents
> > and prevents the macro from being accidently called from elsewhere.
>
> Is this just an access check, or the scope of a binding: can the
> same symbol name a different macro for methods of some other
> class?
If the aforementioned feature is anything like the DEFUN-IN-FLAVOR it
works by installing a definition into an environment which is private
to a specific class.
The Flavors system was oh so much better than CLOS supporting the
programmer who specifies and extends protocols, or interfaces, as they
are known in those other languages. All of the implementation matter
exits to do this in CLOS, but there is nothing to hang your hat on, so
to speak.
Carl Shapiro <·············@panix.com> writes:
> If the aforementioned feature is anything like the DEFUN-IN-FLAVOR
Yes, the aforementioned feature *is* DEFUN-IN-FLAVOR!
DEFUN-IN-FLAVOR, DEFMACRO-IN-FLAVOR and DEFSUBST-IN-FLAVOR
(the latter being how we used to say INLINE) are all the same facility.
> The Flavors system was oh so much better than CLOS supporting the
> programmer who specifies and extends protocols, or interfaces, as they
> are known in those other languages. All of the implementation matter
> exits to do this in CLOS, but there is nothing to hang your hat on, so
> to speak.
Yes! This kind of thing is what my note about "protocols" referred to.
For example, the :REQUIRED-METHODS options of DEFFLAVOR.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Carl Shapiro <·············@panix.com> writes:
> > If the aforementioned feature is anything like the DEFUN-IN-FLAVOR
>
> Yes, the aforementioned feature *is* DEFUN-IN-FLAVOR!
> DEFUN-IN-FLAVOR, DEFMACRO-IN-FLAVOR and DEFSUBST-IN-FLAVOR
> (the latter being how we used to say INLINE) are all the same facility.
>
> > The Flavors system was oh so much better than CLOS supporting the
> > programmer who specifies and extends protocols, or interfaces, as they
> > are known in those other languages. All of the implementation matter
> > exits to do this in CLOS, but there is nothing to hang your hat on, so
> > to speak.
>
> Yes! This kind of thing is what my note about "protocols" referred to.
> For example, the :REQUIRED-METHODS options of DEFFLAVOR.
Along with the myriad of :REQUIRED-mumble options :ABSTRACT-FLAVOR,
:CONSTRUCTOR, :INIT-KEYWORDS, and :MIXTURE should be added onto the
list. Each of these options made significant contributions to the
excellent support for protocol specification. Also, the notion of
families of related classes seems to be completely lost in the object
systems of today.
Inspecting large class libraries which you did not write will give
anybody mental cramps. The object system should do as much as
possible to help the programmer intuit the relationships that exist
among classes. These relationships should be specifiable in a
declarative manner, as was possible in Flavors, rather than by typing
more code into your program, as you are forced to do with CLOS.
Kalle Olavi Niemitalo <···@iki.fi> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > If my description was not clear: it provides a way to define a macro
> > that cannot be invoked except by methods of some class. It documents
> > and prevents the macro from being accidently called from elsewhere.
>
> Is this just an access check, or the scope of a binding: can the
> same symbol name a different macro for methods of some other class?
DEFMACRO-IN-FLAVOR complemented DEFUN-IN-FLAVOR, and they worked
by creating funky function names that EVAL knew to check for in the
appropriate calling context. I think you could have definitions
with the same function name for use with different flavors and for
regular functions (so, yes, this formed another namespace).
But I never used this facility myself and don't remember for sure.
Maybe someone from X3J13 will comment on why this feature was not
persued for ANSI CL -- my guess is that it was too obscure, and
it's not obvious how it should work in a multiple-dispatch language.
······@news.dtpq.com (Christopher C. Stacy) writes:
> 3. Control over the implementation of objects.
> Extensible language facilities for specifying the
> layout (bits) of a slot value. Also, controlling the
> memory (area, or even a wired address) where the object
> will be allocated. These facilities are for foreign
> interface types of things, and for and machine-level
> programming in Lisp.
What are some good examples (papers or implementations) of this?
--
T. Kurt Bond, ···@tkb.mpl.com
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Ray Dillinger <····@sonic.net> writes:
> Common Lisp has CLOS, which is, I think, the single most complete
> set of OO functionality in any language. If anybody can think of any
> OO technique implemented anywhere that's not in CLOS, I'd like to
> hear about it.
Defining visibility within the definition of a method. I started using
CLOS at work, then moved to Java/C#, and now am playing with CLOS
again. I have to say that Lisp's concept of exporting and importing
symbols between packages seems rather clumsy compared to the ability
to define methods as public or private.
I realise they aren't *quite* doing the same thing, but I still find
that I'd like to be able to declare a method as 'private' in
CLOS. Maybe I've just been on the dark side too long ...
Nick
Nick Lacey <··········@pobox.com> writes:
> Ray Dillinger <····@sonic.net> writes:
>
> > Common Lisp has CLOS, which is, I think, the single most complete
> > set of OO functionality in any language. If anybody can think of any
> > OO technique implemented anywhere that's not in CLOS, I'd like to
> > hear about it.
>
> Defining visibility within the definition of a method. I started using
> CLOS at work, then moved to Java/C#, and now am playing with CLOS
> again. I have to say that Lisp's concept of exporting and importing
> symbols between packages seems rather clumsy compared to the ability
> to define methods as public or private.
What would it mean for a CLOS method to be "private"?
(From whom would it be hidden?)
······@news.dtpq.com (Christopher C. Stacy) writes:
> What would it mean for a CLOS method to be "private"?
> (From whom would it be hidden?)
From anything that wasn't supposed to access it ...
In Lisp, any relatively complex application has to use different
packages to maintain separate symbol-spaces so as to avoid name
conflicts. I can't just look at a class definition to see what the
published interface for the class is. I have to worry about the
package file, the build file, the order in which files are loaded, and
so on. If I find that I need a symbol that isn't exported, I can grab
it using a '::', it's ok, I'll export it properly later, I'll just put
a comment in to remind myself ... I know, no-one forces programmers to
use '::', but the very fact that it's there suggests to me that Lisp
doesn't take the public/private distinction as seriously as Java.
In Java/C#, I can declare certain methods to be public, and the others
I can just forget about if all I want to do is use the class
elsewhere. I don't need to declare separate packages or assemblies.
The private/public distinction provides a clear and watertight
distinction between the interface and the internal workings of the
class.
I should add: I'm not knocking Lisp - I wouldn't be using it if I
didn't like it, and CLOS is by far the most powerful object system
I've used, Java and C# being the others. Inter-class visibility is one
area of Lisp that I still find slightly arcane, and this is one area
which I think Java handles better than Lisp .. but maybe I just
haven't learned how to use packages properly yet, this is quite
possible.
Regards,
Nick
Nick Lacey <··········@pobox.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > What would it mean for a CLOS method to be "private"?
> > (From whom would it be hidden?)
>
> From anything that wasn't supposed to access it ...
I am asking specifically how you would characterize those "anything"s.
······@news.dtpq.com (Christopher C. Stacy) writes:
> > > What would it mean for a CLOS method to be "private"?
> > > (From whom would it be hidden?)
> >
> > From anything that wasn't supposed to access it ...
>
> I am asking specifically how you would characterize those
> "anything"s.
Symbols representing classes or generic functions.
Regards,
Nick
Nick Lacey <··········@pobox.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > > > What would it mean for a CLOS method to be "private"?
> > > > (From whom would it be hidden?)
> > >
> > > From anything that wasn't supposed to access it ...
> >
> > I am asking specifically how you would characterize those "anything"s.
>
> Symbols representing classes or generic functions.
Sorry if I'm being dense, but I don't understand your answer.
You said that you wanted to have "private methods" (which is
to say, certain functions); I am asking how you to define "private",
first by telling me whom you want to protect these functions from.
For example, in C++, private members are only accessible within the
lexical scope of the defining class body. It is the other class
definitions that these members are hidden from. So I am asking you to
think about who the corresponding parties and elements would be in Lisp.
······@news.dtpq.com (Christopher C. Stacy) writes:
> > > > > What would it mean for a CLOS method to be "private"?
> > > > > (From whom would it be hidden?)
> So I am asking you to think about who the corresponding parties and
> elements would be in Lisp.
I wouldn't want them to be visible outside the symbol-space within
which they are defined. In Lisp the smallest things these
symbol-spaces can be are packages - in C++/Java, they are classes.
I do accept that it doesn't make sense to define a method as "public"
or "private" in CLOS, due to the way methods are defined and called.
Nick
Nick Lacey <··········@pobox.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > > > > > What would it mean for a CLOS method to be "private"?
> > > > > > (From whom would it be hidden?)
>
> > So I am asking you to think about who the corresponding parties and
> > elements would be in Lisp.
>
> I wouldn't want them to be visible outside the symbol-space within
> which they are defined. In Lisp the smallest things these
> symbol-spaces can be are packages - in C++/Java, they are classes.
And of course you've already got that: packages define your
symbolic API by exporting the intended symbols.
> I do accept that it doesn't make sense to define a method as "public"
> or "private" in CLOS, due to the way methods are defined and called.
So let's go back to your original complaints:
Nick Lacey <··········@pobox.com> writes:
> I can't just look at a class definition to see what the published
> interface for the class is. I have to worry about the package file,
> the build file, the order in which files are loaded, and so on.
To get a handle on a method, you pretty much need to know its function name.
So to make a method "private", you need to secret its name.
But by default, this is already the case! You are writing code in your
own package, and all of your function names are private (not exported).
Maybe your problem is that you are not creating enough packages,
and are just glomming lots of things together?
Your talking about the "package file" and "build file" and their
order suggests that your package definitions are scattered all
over the place in some weird way. But there's only one DEFPACKAGE
for your package, and the EXPORT statements can be done right there
up front, or next to the DEFCLASS or DEFMETHOD, as you prefer.
And those don't have very much to do with files, per se.
> If I find that I need a symbol that isn't exported, I can grab
> it using a '::', it's ok, I'll export it properly later, I'll just put
> a comment in to remind myself ... I know, no-one forces programmers to
> use '::', but the very fact that it's there suggests to me that Lisp
> doesn't take the public/private distinction as seriously as Java.
This is the feature that allows you to go ahead and violate
someone's code in an emergency. This is considered "serious".
> In Java/C#, I can declare certain methods to be public, and the others
> I can just forget about if all I want to do is use the class
> elsewhere. I don't need to declare separate packages or assemblies.
In Lisp, you just declare certain methods (function names) to be
public, and the others you can just forget about. In languages
like C++ and Java, the concepts of files, classes, and namespaces
are all conflated inappropriately. That allows you to only have
to mention the (class) name once. But it imposes severe restrictions
on how you can organize your code (for example, the methods are owned
by classes). Lisp is more flexible, and you have to put the name of
your public methods in one more place.
Of course, if you think that's too much trouble, you could have a
DEFMETHOD-PUBLIC macro that would expand into a DEFMETHOD followed
by an EXPORT.
> Inter-class visibility is one area of Lisp that I still find
> slightly arcane, and this is one area which I think Java handles
> better than Lisp .. but maybe I just haven't learned how to use
> packages properly yet, this is quite possible.
Lisp programs are not really centered around classes or files.
······@news.dtpq.com (Christopher C. Stacy) writes:
> So to make a method "private", you need to secret its name. But by
> default, this is already the case! You are writing code in your own
> package, and all of your function names are private (not exported).
Yes, I came to realise this as I was writing these posts. I ended up
deleting a lot of what I'd written. ;-)
> Maybe your problem is that you are not creating enough packages,
> and are just glomming lots of things together?
I think part of my problem is that I'm still trying to understand how
packages work, and the best way to organise things.
> Your talking about the "package file" and "build file" and their
> order suggests that your package definitions are scattered all over
> the place in some weird way.
Currently I have one global package file which is loaded first, and
then a global build file which loads the build files for the
individual packages.
> Lisp is more flexible, and you have to put the name of your public
> methods in one more place.
>
> Of course, if you think that's too much trouble, you could have a
> DEFMETHOD-PUBLIC macro that would expand into a DEFMETHOD followed
> by an EXPORT.
That's a nice idea .. I shall look into that.
Many thanks for your detailed reply,
Nick
······@news.dtpq.com (Christopher C. Stacy) writes:
> Of course, if you think that's too much trouble, you could have a
> DEFMETHOD-PUBLIC macro that would expand into a DEFMETHOD followed
> by an EXPORT.
I don't know if this was added to CLISP or not, but Sam Steingold
recently talked about an EXPORTING package which exports defun,
defmethod etc. so that one could write:
(exporting:defmethod ...<normal defmethod code>)
to do exactly what you describe.
I tend to prefer this approach to some-package:defmethod-public (but I
never used any of these myself in code).
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Nick Lacey wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>
>>>>What would it mean for a CLOS method to be "private"?
>>>>(From whom would it be hidden?)
>>>
>>>From anything that wasn't supposed to access it ...
>>
>>I am asking specifically how you would characterize those
>>"anything"s.
>
>
> Symbols representing classes or generic functions.
>
> Regards,
>
> Nick
>
>
>
but you can access classes and generic functions without
having to go through their name symbols.
It would be nice if CLOS allowed (somehow) the calculation
of the applicable methods to be a function of the number
of arguments and not just the classes of arguments. I.e.,
i'd like to create a different generic function for 2
argument invocations and 3 argument invocations etc.
I do not see an easy way to specify this however,
especially if &rest or &optional are used in the
lambda list.
(defgeneric myfun (a b))
(defgeneric myfun (a b c))
(defmethod myfun ((a number) (b string))
....)
(defmethod myfun ((a number) (b string) (c (eql nil)))
(myfun a b))
I understand that Java does something like this. (not sure
because i've never really even seen a java program ;-)
A method within a class can be defined with several
different numbers of arguments, and the dispatch mechanism
decides which method to call depending on the class of the
first arguemnt and the number of remaining arguments.
I imagine it is much easier to specify if you do
not have to care about multiple dispatch.
-jim
Jim Newton <·····@rdrop.com> writes:
> It would be nice if CLOS allowed (somehow) the calculation
> of the applicable methods to be a function of the number
> of arguments and not just the classes of arguments. I.e.,
> i'd like to create a different generic function for 2
> argument invocations and 3 argument invocations etc.
>
> I do not see an easy way to specify this however,
> especially if &rest or &optional are used in the
> lambda list.
> I understand that Java does something like this. (not sure
> because i've never really even seen a java program ;-)
> A method within a class can be defined with several
> different numbers of arguments, and the dispatch mechanism
> decides which method to call depending on the class of the
> first arguemnt and the number of remaining arguments.
> I imagine it is much easier to specify if you do
> not have to care about multiple dispatch.
Not exactly. Java has method "overloading", which is sort of the same thing
as "multiple dispatch", except that it's done statically. At compile-time,
the caller must specify the type of the arguments for the method call.
This is done by declaring the type of, or by casting, the variables
that are used in the method call.
Java does not quite have optional arguments (or keyword, or rest args)
but the method signatures can have different numbers of arguments.
void foo (float x, float y)
void foo (float x, integer y)
void foo (float x, integer y, float z)
void foo (float x, float y, integer z)
Note that there's an implicit argument (not mentioned in the
arglist there) which is an object of the defining class.
By contrast, CLOS dispatches dynamically on the types of the objects
(generally not known until run-time); but it only dispatches on the
required arguments (which are referred to as the "specialized parameters").
Optionalarguments are allowed, but you can't dispatch' on them; there's no
way to specify their type, and all method argument lists must be congruent.
So I think you are asking to be able to write things like this:
(defgeneric foo (o x y &optional z)
(defmethod foo ((o obj) (x float) ((y integer)) &optional ((z float))))
(defmethod foo ((o obj) (x float) ((y float)) &optional ((z integer))))
(defmethod foo ((o obj) (x float) ((y float)) &optional ((z t) 'unity z-supplied-p)))
That seems cool, but I don't recall missing this feature.
Do you have some example applications that would benefit from
structuring the function calling and methods in this extended way?
Also, what would be the performance implications of allowing this?
Jim Newton wrote:
> It would be nice if CLOS allowed (somehow) the calculation
> of the applicable methods to be a function of the number
> of arguments and not just the classes of arguments. I.e.,
> i'd like to create a different generic function for 2
> argument invocations and 3 argument invocations etc.
I'm already doing that; Generic functions are so darned
useful I couldn't imagine doing without them, and I'm
dispatching on call arity and supplied keyword args, as
well as arg types.
> I do not see an easy way to specify this however,
> especially if &rest or &optional are used in the
> lambda list.
There are several mutually-interfering sets of things
you can do with arguments. The central feature of the
lisp I'm working on is an extended lambda form that
allows syntax-like functions to be defined. Ordinary,
applicable, first-class functions can be defined to
get promises instead of values for selected arguments
(delaying application until an explicit force), or bind
their own continuation to a formal argument, or to
get some or all of their arguments in quoted form,
along with a pointer to the caller's environment so
they can construct modified forms and eval them in the
calling environment if desired.
This completely eliminates the need for macrology of
all types, except that the moral equivalent of current
macrology may be done by the compiler as an optimization.
Such techniques present no real problems with non-generic
functions, and even in generic functions they can be
easily combined with keyword arguments, allowing dispatch
on which keywords are present, and are easily combined
with dispatch on call arity - but they sharply limit
dispatching on type. In a dialect where functions are
responsible for evaluating their own arguments, the
runtime won't be able to do dispatching on types because
evaluation has not yet actually taken place when the
generic function is called. So the generic function
has to do some evaluation before it can dispatch to
a method, and the method, as compiled, will use the
mechanism for getting its already-evaluated arguments
in quoted form from the generic function, along with
"pass-through" of caller environment and continuuation
if it takes those explicitly.
So what happens is that the system looks at the
lambda list of each method and figures out which
arguments the generic function can safely evaluate
before dispatching to one of its methods (ie, which
args, when present, are evaluated normally in
*every* method's lambda list) and excludes others
from the inputs to the dispatcher, because whether
or not they'll be evaluated depends on the method.
So generic functions have to be defined with a
minimum promise to the compiler about their
argument list, telling them which arguments they
can evaluate for dispatch. But methods can have
different arities, as long as the dispatcher can
figure out which method to call.
Keyword arguments are always good because keywords
are always input for the dispatcher; however, all
calls with arity greater than the minimum number
of args any method with rest arguments can have,
must withhold call arity from the dispatcher, and
all calls with more args than the number evaluated
by the generic function before dispatch must withhold
the types of subsequent args from the dispatcher. So
methods with rest arguments have to be distinguishable
by argument types or keywords before either of those
numbers is reached, and the system must reject
definition of a new method violating this rule as an
error.
I think that because of their unfortunate interaction
with method dispatch, I may drop optional args
altogether, forcing the use of explicit keyword args
instead, at least in the methods of generic functions;
and perhaps in all functions.
> I imagine it is much easier to specify if you do
> not have to care about multiple dispatch.
Now there's an understatement; but multiple dispatch
is definitely worthwhile.
Bear
Nick Lacey <··········@pobox.com> writes:
> I realise they aren't *quite* doing the same thing, but I still find
> that I'd like to be able to declare a method as 'private' in
> CLOS. Maybe I've just been on the dark side too long ...
Think of it this way:
A generic function in CLOS is supposed to be generic in the same way
`+' is generic --- it can be called on all sorts of different types of
arguments and `the right thing' ultimately happens.
So suppose someone says `I want to add a private method to +'. What
would that mean? Do you only want some sections of code to be able to
add things of certain types? Since nearly anybody, anywhere might
call +, what should happen if they happened to pass an object that
matched the `private' method?
In CLOS it makes more sense to hide abstractions at the
generic-function level rather than at the method level.
Ray Dillinger <····@sonic.net> writes:
> features that are seldom or never used? Are there features the use
> of which, now that we have experience of them, usually indicates a
> design mistake?
You may check this paper by Henry Baker:
CLOStrophobia: Its Etiology and Treatment
http://home.pipeline.com/~hbaker1/CLOStrophobia.html
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Ray Dillinger wrote:
> Common Lisp has CLOS, which is, I think, the single most complete
> set of OO functionality in any language. If anybody can think of
> any OO technique implemented anywhere that's not in CLOS, I'd like
> to hear about it.
CLOS doesn't have a static type system. ;-)
CLOS doesn't provide encapsulation. (I think that encapsulation is
usually overrated, but that's sometimes criticized, and may indeed be
useful for safety critical things.)
CLOS allows methods to be defined independently from classes, but
doesn't allow slots to be defined from the outside in a similar way.
It's not straightforward to achieve that, but for example
http://www.informatik.uni-ulm.de/rs/mitarbeiter/ch/apples/ has a nice
design for this.
> Has anybody gathered statistics on CLOS usage patterns? Are there
> features that are seldom or never used? Are there features the use
> of which, now that we have experience of them, usually indicates a
> design mistake?
I think that forward referenced classes are not the best idea. They make
implementing the MOP more complicated than necessary, and don't provide
a lot of bang for the buck.
Slots with class allocation are also somewhat superfluous, and are
unnecessarily hard to use because you always need an instance of a class
to access :class slots. Simply defining slots on the class metaobject is
simpler, but requires you to define methods on validate-superclass.
Maybe class metaobjects should by default provide a property list that
can be used by base-level code.
I also don't understand how the inheritance rule for the slot option
:type can yield something useful.
The algorithm for determining the class precedence list is not the best
one (but still works well in practice). See
http://www.webcom.com/haahr/dylan/linearization-oopsla96.html for more
details.
I think that method combinations are a very good idea and very useful,
but allowing :before, :after and :around methods by default can make
your program less understandable. It would be better if the default
method combination were one that allows only primary methods, and
programmers were required to declare the 'standard method combination
(with :before, :after and :around methods) if they want that kind of
extensibility.
The effects of change-class on an object that is already in use
somewhere else are not well-understood.
The defmethod macro doesn't allow for declaration of the method class
and/or method options.
None of these problems are fundamental ones, though. They can all be
fixed through the CLOS MOP.
I highly recommend reading the papers at
http://www.dreamsongs.com/CLOS.html , especially "The Shape of the
Design Space". Papers about LOOPS are also good to understand CLOS
better (overview at http://www2.parc.com/istl/members/stefik/ , papers
at http://www2.parc.com/istl/groups/hdi/ ), as well as some of the
papers about Flavors.
Cheers,
Pascal
Pascal Costanza <··@p-cos.net> writes:
> CLOS doesn't provide encapsulation. (I think that encapsulation is
> usually overrated, but that's sometimes criticized, and may indeed be
> useful for safety critical things.)
I balked at this initially. Then I thought about how Java and C++
programmers often do "encapsulation". A very common case is something
like this:
class Foo {
int x;
public int getX() {return x;}
public void setX(int newX) {x = newX;}
}
So much for encapsulation. Another way I've seen encapsulation broken
is with something like this:
class Bar extends Foo {
public void frob() { /* do something with x */ }
}
CLOS's lack of Java and C++ style encapsulation no longer bothers me.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
>
> Pascal Costanza <··@p-cos.net> writes:
>
> > CLOS doesn't provide encapsulation. (I think that encapsulation is
> > usually overrated, but that's sometimes criticized, and may indeed be
> > useful for safety critical things.)
>
> I balked at this initially. Then I thought about how Java and C++
> programmers often do "encapsulation". A very common case is something
> like this:
>
> class Foo {
> int x;
> public int getX() {return x;}
> public void setX(int newX) {x = newX;}
> }
But this is also done because, in Java, methods are dynamically
dispatched, but references to slots (instance variables) are done
statically. That means that if some subclass of Foo redefines "x", then
any references to Foo.x would get the wrong variable.
Another reason is to allow more hiding of the implementation details.
By using only methods to access "x", it can later be changed from a
slot (instance variable) into something virtual or computed. This is
also a consequence of a method call looking syntactically different from
a variable access. You get this for flexibility for free in CLOS
because accessors are method calls. [OK, you can subvert it with
SLOT-VALUE, but then you get what you deserve...]
The other reason for doing this, is that encapsulation at the instance
variable level is not differentiated between read and write access.
With methods you get finer-grained control of the access.
So, of these three reasons, two don't apply to Lisp, and the third can
be (mostly) handled by appropriate method definitions.
I personally don't believe in absolutely enforcing these sorts of
restrictions, since it often makes it hard to modify or adapt existing
code.....
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > Pascal Costanza <··@p-cos.net> writes:
> >
> > > CLOS doesn't provide encapsulation. (I think that encapsulation is
> > > usually overrated, but that's sometimes criticized, and may indeed be
> > > useful for safety critical things.)
> >
> > I balked at this initially. Then I thought about how Java and C++
> > programmers often do "encapsulation". A very common case is something
> > like this:
> >
> > class Foo {
> > int x;
> > public int getX() {return x;}
> > public void setX(int newX) {x = newX;}
> > }
>
> But this is also done because, in Java, methods are dynamically
> dispatched, but references to slots (instance variables) are done
> statically. That means that if some subclass of Foo redefines "x", then
> any references to Foo.x would get the wrong variable.
>
> Another reason is to allow more hiding of the implementation details.
> By using only methods to access "x", it can later be changed from a
> slot (instance variable) into something virtual or computed. This is
> also a consequence of a method call looking syntactically different from
> a variable access. You get this for flexibility for free in CLOS
> because accessors are method calls. [OK, you can subvert it with
> SLOT-VALUE, but then you get what you deserve...]
>
> The other reason for doing this, is that encapsulation at the instance
> variable level is not differentiated between read and write access.
> With methods you get finer-grained control of the access.
>
> So, of these three reasons, two don't apply to Lisp, and the third can
> be (mostly) handled by appropriate method definitions.
>
> I personally don't believe in absolutely enforcing these sorts of
> restrictions, since it often makes it hard to modify or adapt existing
> code.....
My point was that Java & C++ programmers (not exclusively) often use
get/set methods in a way that breaks down the abstraction layer rather
than provides it. The whole point of encapsulation, whether it's
enforced by the language or just followed by programmer convention is
to localize implementation details and to provide a layer of
abstraction.
I would also question the practice of coding a subclass in a way that
it has knowledge of the internals of its superclass.
I absolutely agree that you should only communicate with an object via
its published interface.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Then I thought about how Java and C++ programmers often do
> "encapsulation".
But that's not the fault of the languages, but rather of some
ill-conceived cultural ideas that get taught and learned faster than
they can be unlearned and refuted.
The "setter" member function idiom is akin to first installing a lock
on a door, then installing a huge green button next to the lock
labeled "Enter and vandalize anyway". I have yet to see a legitimate
class that was not broken by such a function.
--
Steven E. Harris
Steven E. Harris wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>>Then I thought about how Java and C++ programmers often do
>>"encapsulation".
>
> But that's not the fault of the languages, but rather of some
> ill-conceived cultural ideas that get taught and learned faster than
> they can be unlearned and refuted.
>
> The "setter" member function idiom is akin to first installing a lock
> on a door, then installing a huge green button next to the lock
> labeled "Enter and vandalize anyway". I have yet to see a legitimate
> class that was not broken by such a function.
I agree that encapsulation doesn't work in practice in those languages.
However, I think you have got the "genealogy" wrong.
The reason why Java programmers want encapsulation for fields is this:
Fields are considered to be something very different from methods, more
different than slots and methods are in CLOS. In C++ and Java, fields
are actually thought of to be the storage locations that you can
directly read and write. Effectively, field accesses are assumed to be
translated into direct array accesses by the compiler, because this is
"clearly" the most efficient way to implement fields.
Now usually you want to have some control over field accesses in order
to be able to react to field accesses. That's when getters and setters
come into play. They allow you to, say, notify observers that a field
has changed in order to, say, update views on the screen that visualize
the value of that field. In order to be really sure that you get all
field accesses, you turn those fields into private fields, and only make
the setters and getters public. Then you can be sure that noone
circumvents your update protocols.
Of course, the debug API usually still allows you to circumvent private
restrictions, but let's not confuse the theoreticians too much. ;)
It just doesn't occur to some people that the boundary between fields
and methods doesn't need to be that strict.
Nevertheless, my point just is that from a certain perspective it can
appear to make sense that fields can be private and at the same time,
there are public getters and setters defined on them.
Pascal
Pascal Costanza <··@p-cos.net> writes:
[...]
> Now usually you want to have some control over field accesses in
> order to be able to react to field accesses. That's when getters and
> setters come into play. They allow you to, say, notify observers
> that a field has changed in order to, say, update views on the
> screen that visualize the value of that field. In order to be really
> sure that you get all field accesses, you turn those fields into
> private fields, and only make the setters and getters public. Then
> you can be sure that noone circumvents your update protocols.
Also, of course, having setters and getters allows you to hide the
implementation: users of the class don't need to know which things
you've decided to use as fields, and which are calculated in some way.
In a richer language you needn't do that (since you can modify the
behaviour of getting or setting fields), but in Java or C++ there's a
definite syntactic difference between getting/setting a field and
calling a method, so if you want to hide that then everything has to
turn into a method.
[...]
Bruce Stephens <············@cenderis.demon.co.uk> writes:
> Also, of course, having setters and getters allows you to hide the
> implementation: users of the class don't need to know which things
> you've decided to use as fields, and which are calculated in some way.
The distinction may become visible when the calculations are not
reversible. For example, you could have a complex-number object
with four apparent fields: real, imag, magnitude, and phase. If
only real and imag are stored as actual fields (so that addition
is fast), and the polar coordinates are computed, then changing
the magnitude to zero will cause the phase to be lost; moreover,
later changes of the phase will not be fully preserved either.
I suppose a clever interface would remember which representation
was set last, and then compute the other from it on demand.
On the other hand, if one sets first the real and imaginary parts
and then the phase, how does the object know the user wanted to
preserve the magnitude? He might have wanted to preserve the
imaginary part instead, as that was set last. So perhaps field
semantics are not quite right here and one should instead have
setter functions that explicitly document what they preserve.
Paul Foley wrote:
> On Sun, 27 Mar 2005 16:38:45 +0200, Jim Newton wrote:
>
>
thanks for your input. i never intended to claim
that this was an unsolvable problem. of course it
can be done with fancy &rest &optional arguments
and writing my own dispatch mechanism and agument
parser.
my original point to respond to the question of what
i wish CLOS was able to do. and i thought that java
had tried to solve this problem. but not being a java
expert i do not know if java solved it in a nice way
or now.
>
> (defgeneric myfun/2 (a b))
> (defgeneric myfun/3 (a b c))
>
>
> You know how many arguments you're using, so there's nothing gained by
> using the same name in both cases, but no pain involved in putting the
> arg-count in the name.
>
This only works if you have the argument lists at compile
time. If the argument lists are being generated at runtime
then you would have to build your own dispatch mechanism.
(loop while (setf line (get-another-line))
do
(apply (cond
((2 = (length line))
#'myfun/2)
((3 = (length line))
#'myfun/3))
((4 = (length line))
#'myfun/4)
((5 = (length line))
#'myfun/5)))
some-prefix line))
yes yes yes i realize that even without an object system
you could write a functions that take optional arguements
and have the functions parse the argument lists themselves.
My comment was just that it would be nice if the
generic dispatch mechanism could do that for me.
> [If you really want to call it through a single name, just do
>
> (defun myfun (a b &optional (c nil c-p))
> (if c-p (myfun/3 a b c) (myfun/2 a b)))
>
> but since you still have to define methods on the explicit names, I
> wouldn't bother]
>
What you have done here is to write your own discrimitating
function.
Here is an example of some of the input i'm parsing.
(nr02d1 a90940( A1(a23518(15)) A2(a90941) ZN(a90924)))
(inv0d1 a83438( I(a83384) ZN(a83439)))
(xr03d1 a83430(2)( A1(a83392) A2(a83429) A3(a83332) Z(a83431)))
(ad01d1 a83424(3) 4 ( A(a83332) B(a83384) CI(a83423) S(a83425)
CO(a83426)))
I'd like to write my parser as follows.
(defgeneric parse-line (p a b c))
(defgeneric parse-line (p a b c d))
(defgeneric parse-line (p a b c d e))
(defmethod parse-line ((parser parser)
(cell-name symbol)
(inst-name symbol)
(inst-terms list))
...)
(defmethod parse-line ((parser parser)
(cell-name symbol)
(inst-name symbol)
(bit-range list)
(inst-terms list))
...)
(defmethod parse-line ((parser parser)
(cell-name symbol)
(inst-name symbol)
(bit-range list)
(special fixnum)
(inst-terms list))
...)
Then the parser looks something like this
(let (( parser (make-instance 'parser)))
(loop while (setf line (get-another-line))
do
(apply #'parse-line parser line)))
This would allow me to write a different method for every
possible format the input lines can be expected in.
Whenever i discover a new format of line i can simply
add a new method.
You know the more i think about this, the more i'm
convinced it could be done with the MOP. I need to
somehow write a generic function meta class which
allows multiple lambda lists of various lengths.
Ray Dillinger wrote:
> Common Lisp has CLOS, which is, I think, the single most complete
> set of OO functionality in any language. If anybody can think of
> any OO technique implemented anywhere that's not in CLOS, I'd like
> to hear about it.
Mobile objects :-J
Steven Shaw wrote:
> Ray Dillinger wrote:
>
>> Common Lisp has CLOS, which is, I think, the single most complete
>> set of OO functionality in any language. If anybody can think of
>> any OO technique implemented anywhere that's not in CLOS, I'd like
>> to hear about it.
>
>
> Mobile objects :-J
You mean, serializable with read/write invariance on separate systems?
That's, uh, possible, I guess, but each object would have to encapsulate
all its methods and class relationships.
Or did you mean something else?
Bear