If the name you want to use for a CLOS method is already bound to an
existing defun'd function. Is there a standard "best" alternative that
people usually use? Should you define a package for it, or use a
different name, or just do whatever works?
--
Dan
www.prairienet.org/~dsb
On Feb 20, 3:15 pm, Dan Bensen <··········@cyberspace.net> wrote:
> If the name you want to use for a CLOS method is already bound to an
> existing defun'd function. Is there a standard "best" alternative that
> people usually use? Should you define a package for it, or use a
> different name, or just do whatever works?
I will almost always use a different name, because I try to avoid
shadowing symbols from the "CL" package if at all possible, and I
can't say I've seen a whole lot of code that does things differently.
Cheers,
Pillsy
Dan Bensen wrote:
> Should you define a package for it
I mean a package for a group of related functions that can act on that
class, not a whole package for just one function.
--
Dan
www.prairienet.org/~dsb
Pillsy wrote:
> I will almost always use a different name, because I try to avoid
> shadowing symbols from the "CL" package if at all possible, and I
> can't say I've seen a whole lot of code that does things differently.
So, not to vent too heavily about CLOS, suppose a new language with a
snappy three-letter name was currently being developed as a modernized
upgrade to CL. Would it make sense for such a language to have a
generic function called "oref" that accesses things in an automatically
generated object namespace? A method call might look something like this:
((oref my-obj foo) args)
Would there be any problems with something like this?
It seems like it would be convenient.
--
Dan
www.prairienet.org/~dsb
Dan Bensen <··········@cyberspace.net> writes:
> Pillsy wrote:
>> I will almost always use a different name, because I try to avoid
>> shadowing symbols from the "CL" package if at all possible, and I
>> can't say I've seen a whole lot of code that does things differently.
>
> So, not to vent too heavily about CLOS, suppose a new language with a
> snappy three-letter name was currently being developed as a modernized
> upgrade to CL. Would it make sense for such a language to have a
> generic function called "oref" that accesses things in an
> automatically generated object namespace? A method call might look
> something like this:
>
> ((oref my-obj foo) args)
>
> Would there be any problems with something like this?
> It seems like it would be convenient.
What's wrong with (foo:my-obj args) ?
Implementing something like ((oref my-obj foo) args) in Common Lisp is difficult.
You'd have to embed it into a macro call to have a chance to parse it
and transform it to what you want.
In CL, namespace resolution is done at read time, with the qualified symbols.
In CL, the first object of a form is not interpreted at run time, but
at compilation time. It must be the name of a function (or macro or
special operator), that is either a symbol or a lambda expression.
(oref my-obj foo) is neither.
But if you're considering a non CL language, then yes, why not,
anything's possible.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
Pascal Bourguignon wrote:
> What's wrong with (foo:my-obj args) ?
I'm not sure I understand you. I mean foo to be a method, not a
package, and my-obj is an object. (my-pakg:foo my-obj args) requires
the namespace to be defined separately from the object.
> ... the first object of a form ... must be the name of a function ...
> that is either a symbol or a lambda expression.
> (oref my-obj foo) is neither.
Oh, darn. This looks like it's related to the separate function and
variable namespaces. So CL would need (funcall (oref my-obj foo) args),
which isn't quite as slick.
> But if you're considering a non CL language, then yes, why not,
For the purposes of this thread, I'm only interested in languages that
support full CL-style macros (evaluated, nonhygienic). It looks like
object namespaces require a Lisp-1 to be convenient, so I guess that
explains why it's not in CLOS.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> Pascal Bourguignon wrote:
>
>> What's wrong with (foo:my-obj args) ?
>
> I'm not sure I understand you. I mean foo to be a method, not a
> package, and my-obj is an object. (my-pakg:foo my-obj args) requires
> the namespace to be defined separately from the object.
>
>> ... the first object of a form ... must be the name of a function ...
>
> > that is either a symbol or a lambda expression.
>
>> (oref my-obj foo) is neither.
>
> Oh, darn. This looks like it's related to the separate function and
> variable namespaces. So CL would need (funcall (oref my-obj foo) args),
> which isn't quite as slick.
Slick? Is that a value I do not know about in languae design? CL is
about as far from slick as you can get. Bloated, verbose, redundant...
the only thing it is good for is application development, which I know
is irrelevant to Lispers since they do not write any. If they are doing
anything they are trying to get Linux to run today or writing their own
Lisp and agonizing publicly over these nonsense issues.
(funcall (oref my-bj foo) args)... oh, the horror! Oh, the humanity!
I think I answered my own question.
kzo
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
Ken Tilton wrote:
> Slick? Is that a value I do not know about in languae design?
Apparently so. The formula is approximately slick = (sexy + concise)/2.
Or maybe it's sqrt(sexy*concise).
> CL is about as far from slick as you can get. Bloated, verbose,
redundant...
> (funcall (oref my-bj foo) args)... oh, the horror! Oh, the humanity!
I usually use a more abstract, generalized definition of "slick" that
encompasses large-scale issues of bloat and redundancy. For large
applications that benefit from macros, CL can be quite slick indeed.
That's the whole reason I like it. :)
--
Dan
www.prairienet.org/~dsb
Dan Bensen <··········@cyberspace.net> writes:
> Ken Tilton wrote:
>> Slick? Is that a value I do not know about in languae design?
>
> Apparently so. The formula is approximately slick = (sexy +
> concise)/2. Or maybe it's sqrt(sexy*concise).
It seems your definition of conciseness involves short identifiers; in
particular you seem to concerned that short names are more likely to
collide, and to be bothered by the consequences of name collisions for
generic functions, which have lambda list congruence requirements.
But this definition of "slick" is problematic, because there's
concise, and then there's concise. CL has many ways of organizing
code to improve modularity and avoid redundancy, with the result that
you can acheive global conciseness even when code is locally wordy.
Macros are one such tool. Constructs such as TAGBODY and maybe
UNWIND-PROTECT could probably have had longer names than they do
without burdening application writers, because they're mostly only
used in the expansions of macros like DO<something> and
WITH-<something>.
But macros aren't the only trick in the bag, and they're less
interesting for this thread than some patterns that occur in various
CLOS programs. For example, consider the Gray Streams extension for
user-defined streams. This extension provides a generic function
protocol where all the functions have names like
stream-read-<something> and stream-write-<something>, and they
dispatch on their first argument (which is therefore mandatory). Or
consider CLOS itself, when implemented via a MetaObject Protocol. The
CLOS MOP includes generic functions with ponderously long names and
lots of mandatory arguments; things like "slot-value-using-class",
which dispatches on three arguments.
But if one counts the number of places where the Gray Streams and MOP
functions are actually called, one finds the number to be very low:
grepping today's SBCL sources, there are 7 calls to stream-read-char,
and about 10 calls to slot-value-using-class. More importantly, one
rarely, probably never, calls these functions directly: people who
want to extend streams or CLOS typically have only to define some
classes (often mixins) add some methods that specialize on the new
classes (often auxiliary methods that don't need to know anything
about any other methods on the function).
It's precisely /because/ CLOS invisibly handles the multiple
inheritance, multiple dispatch, and primary and auxiliary method
combination that well-factored libraries can usually be extended with
a few simple methods, and so applications can be shorter on the whole,
even when tokens and argument lists are long.
So you can get globally concise even with names that are long (and so
are less likely to collide, even in shared namespaces). Whether any
of this is sexy, I can't say.
Have fun,
RmK
Richard M Kreuter wrote:
> It seems your definition of conciseness involves short identifiers ...
> But this definition of "slick" is problematic, ...
> you can acheive global conciseness even when code is locally wordy.
Which is why I don't use such a shallow, short-sighted definition. As I
wrote only a few lines later in the same message you quote:
> I usually use a more abstract, generalized definition of "slick" that encompasses large-scale issues of bloat and redundancy.
> Have fun
Likewise.
--
Dan
www.prairienet.org/~dsb
On Feb 21, 12:27 am, Dan Bensen <··········@cyberspace.net> wrote:
> So CL would need (funcall (oref my-obj foo) args),
> which isn't quite as slick.
Or, I dunno ([my-ob foo] args), say, where [x y] is read as (lambda ()
(oref x y)) or something. Or, if you want: [my-ob foo args], by
extending the reader macro a bit in a pretty obvious way. This kind
of thing is very easy in CL.
--tim
Dan Bensen <··········@cyberspace.net> writes:
> It looks like
> object namespaces require a Lisp-1 to be convenient, so I guess that
> explains why it's not in CLOS.
I would instead argue that the reason it isn't in CLOS is that with
object namespaces, you don't have any sharing. If each object is in its
own namespace, then you won't have any shared references between
objects, and thus the ability to use the SAME name on different objects
goes away. I would think that would defeat some of the benefits of OO
programming.
Furthermore, how is that any improvement on just pre-pending the object
name to all of the symbols used by that object?
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> with object namespaces, you don't have any sharing.
> If each object is in its own namespace, then you won't
> have any shared references between objects,
I don't understand that. It sounds like you're talking about the
ambiguity between the object and global namespaces. Some people find
that confusing, but the global space is usually visible from inside the
object.
> Furthermore, how is that any improvement on just pre-pending the object
> name to all of the symbols used by that object?
It's redundant. It also prevents you from having a symbol named gak in
a class called foo-bar at the same time that you have a symbol named
bar-gak in a class called foo.
:)
--
Dan
www.prairienet.org/~dsb
On Tue, 20 Feb 2007 18:27:33 -0600, Dan Bensen wrote:
> Pascal Bourguignon wrote:
>> What's wrong with (foo:my-obj args) ?
> I'm not sure I understand you. I mean foo to be a method, not a
> package, and my-obj is an object. (my-pakg:foo my-obj args) requires
> the namespace to be defined separately from the object.
>
>> ... the first object of a form ... must be the name of a function ...
> > that is either a symbol or a lambda expression.
>> (oref my-obj foo) is neither.
> Oh, darn. This looks like it's related to the separate function and
> variable namespaces. So CL would need (funcall (oref my-obj foo) args),
> which isn't quite as slick.
To me it looks like you're trying to implement something like ol' method
pasing. So how about:
(send my-object foo arg ...)
or, for the syntactic sugar inclined:
(→ my-object foo :bar baz ... )
>> But if you're considering a non CL language, then yes, why not,
> For the purposes of this thread, I'm only interested in languages that
> support full CL-style macros (evaluated, nonhygienic). It looks like
> object namespaces require a Lisp-1 to be convenient, so I guess that
> explains why it's not in CLOS.
If you can live with the little syntactic wrapper mentioned above you
could do something uggly like:
(→ my-object.foo bar blub baz)
HTH Ralf Mattes
Ralf Mattes wrote:
> To me it looks like you're trying to implement something like ol' method
> pasing. So how about:
> (send my-object foo arg ...)
Looks good. As long as the programmer doesn't have to worry about
packages or crashing namespaces.
--
Dan
www.prairienet.org/~dsb
On 2007-02-21 14:20:09 +0000, Dan Bensen <··········@cyberspace.net> said:
> Ralf Mattes wrote:
> > To me it looks like you're trying to implement something like ol' method
>> pasing. So how about:
>> (send my-object foo arg ...)
> Looks good. As long as the programmer doesn't have to worry about
> packages or crashing namespaces.
It's worth mentioning, perhaps that that was how old flavors worked.
New flavors was more CLOS-like. One of the issues with this style is
that it is often considered to reduce readability of code
significantly. People read from left to right (well, when reading Lisp
they do), and pay more attention to the left of the line when skim
reading. So now your code looks like (ignoring parens in the usual way)
if send ...
send ...
send ...
which means, um better read more carefully (and slowly).
Lisp is conventionally a verb-subject language, so normal Lisp style
(as supported by CLOS, say) emphasises the verbs:
if bad-thing-p ...
fixup-thing ...
carry-on-as-normal ...
(and of course we have a lot of special conditionals to make this more
readable in common cases:
when bad-thing-p ...
fixup-thing ...
)
Lots of languages conventionally thought of as `object oriented' are
subject-verb, so you expect to see
if thing bad
thing fixup
thing carry-on
And you can very easily support this in CL with some small reader-macro
hackery so written out with parens you'd write, for instance:
(if [thing bad]
[thing fixup]
[thing carry-on])
Of course, subject-verb doesn't work too well for multiple-dispatch,
but most conventional OO languages don't have that.
--tim
Tim Bradshaw wrote:
>>> method pasing.
> One of the issues with this style is
> that it is often considered to reduce readability of code
> significantly. People read from left to right
> if send ...
> send ...
> send ...
I've also been wondering what the performance implications would be of
dispatching so many methods from one generic function.
One simple approach might be to use a shorter name, like "!" or some
such thing. It retains a clear logical structure instead of making the
programmer parse long identifiers by eye and manage crowded namespaces.
> And you can very easily support this in CL with some small reader-macro
> hackery
Nah. Not lispy enough :)
--
Dan
www.prairienet.org/~dsb
On 2007-02-21 22:03:42 +0000, Dan Bensen <··········@cyberspace.net> said:
>
> I've also been wondering what the performance implications would be of
> dispatching so many methods from one generic function.
But you're not. SEND is (obviously) a macro.
--tim
Tim Bradshaw wrote:
> SEND is (obviously) a macro.
Hmm... I guess it could expand to something like "(funcall (oref ..." or
"(funcall (get-message-handler ...".
--
Dan
www.prairienet.org/~dsb
Dan Bensen <··········@cyberspace.net> writes:
> Pascal Bourguignon wrote:
>> What's wrong with (foo:my-obj args) ?
> I'm not sure I understand you.
Sorry, it's me who didn't understand you. I thought foo was a
namespace.
> I mean foo to be a method, not a
> package, and my-obj is an object. (my-pakg:foo my-obj args) requires
> the namespace to be defined separately from the object.
As mentionned in the other answers, a classical way to do send a message is:
(send object message arguments...)
In general you can use any symbol for the message:
(send object 'foo arguments...)
So it doesn't matter much where foo comes from and what "overloading"
it might have, since it's only used as a keyword to index the method
table of the object.
In the case of generic functions, we trade some complexity for the
ease to write:
(foo object arguments...)
but indeed, in a classical OOD point of view, it's better and simplier
to write:
(send object 'foo arguments...)
Of course, you can add your own syntactic suggar, such as a reader
macro allowing you to write:
[object foo arguments...]
and even, if you like Objective-C or Smalltalk syntax, to write things
like:
[object displayOn: window at: x : y]
which would read as:
(send object '|displayOn:at::| window x y)
>> ... the first object of a form ... must be the name of a function ...
>> that is either a symbol or a lambda expression.
>> (oref my-obj foo) is neither.
> Oh, darn. This looks like it's related to the separate function and
> variable namespaces. So CL would need (funcall (oref my-obj foo)
> args),
> which isn't quite as slick.
Indeed, (funcall (oref my-obj 'my-method) arguments...)
or: (send my-obj 'my-method arguments...)
>> But if you're considering a non CL language, then yes, why not,
> For the purposes of this thread, I'm only interested in languages that
> support full CL-style macros (evaluated, nonhygienic). It looks like
> object namespaces require a Lisp-1 to be convenient, so I guess that
> explains why it's not in CLOS.
Well, you can use a reader macro to avoid writting the FUNCALL or SEND
symbol. On the other hand, writting send to send a message is not too
bad.
--
__Pascal Bourguignon__ http://www.informatimago.com/
CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.
On Wed, 21 Feb 2007 20:54:23 +0100, Pascal Bourguignon <···@informatimago.com> said:
| ...
| In the case of generic functions, we trade some complexity for the
| ease to write:
|
| (foo object arguments...)
|
| but indeed, in a classical OOD point of view, it's better and simplier
| to write:
|
| (send object 'foo arguments...)
Only if object-centric is better and simpler than function-centric,
which it arguably isn't, but the margins of this post etc...
---Vassil.
--
Our programs do not have bugs; it is just that the users' expectations
differ from the way they are implemented.
Dan Bensen <··········@cyberspace.net> writes:
> Pillsy wrote:
> > I will almost always use a different name, because I try to avoid
> > shadowing symbols from the "CL" package if at all possible, and I
> > can't say I've seen a whole lot of code that does things differently.
>
> So, not to vent too heavily about CLOS, suppose a new language with a
> snappy three-letter name was currently being developed as a modernized
> upgrade to CL. Would it make sense for such a language to have a
> generic function called "oref" that accesses things in an automatically
> generated object namespace? A method call might look something like
> this:
>
>
> ((oref my-obj foo) args)
>
> Would there be any problems with something like this?
> It seems like it would be convenient.
The major problem I see with this is that it binds methods too tightly
to particular objects. Remember that in CLOS, methods don't belong to
objects, but rather to their generic functions instead.
I would think that this also makes it rather inconvenient to share the
method name among different objects without having to resort to this
reference scheme.
I think using the existing namespace mechanism would work fine, since it
makes not commitment to the granularity of the namespace. That means
you can adjust the granularity to best suit the needs of your particular
project and style of coding rather than building an inflexible naming
scheme that reflects only one very narrow coding style.
--
Thomas A. Russ, USC/Information Sciences Institute
Dan Bensen wrote:
> If the name you want to use for a CLOS method is already bound to an
> existing defun'd function. Is there a standard "best" alternative that
> people usually use? Should you define a package for it, or use a
> different name, or just do whatever works?
If that function is in the COMMON-LISP package, then you shouldn't touch
it. If that function is part of vendor-specific extensions, then you
should most probably not touch it either. If it's a function in a
third-party library, it's unlikely to be a good idea to touch it, but
maybe you can get through with it. (But it's probably a good idea to let
the provider of that library know why you want to do this - maybe there
is a case for integrating your changes.)
If it's your own code, you might as well define the function as a
generic function in the first place.
For all remaining cases ;), you could something like the following.
Let's assume, the function is defined like this:
(defun foo (x y z) (some-code-using x y z))
The you could do the following:
(let ((original-foo #'foo))
(defgeneric foo (x y z)
(:method (x y z)
(funcall original-foo x y z))))
It might be better to make sure that the defgeneric form is a top-level
definition. You can achieve this as follows:
(defvar *original-foo* #'foo)
(defgeneric foo (x y z)
(:method (x y z)
(funcall *original-foo* x y z)))
What both variations do is, they define a generic function on which you
can define more specific methods, while using the original function when
none of the parameters is specialized.
However, an attempt to redefine a function as a generic function
typically signals an error. So a way to circumvent that problem is as
follows:
(defvar *original-foo* #'foo)
(defgeneric new-foo (x y z)
(:method (x y z)
(apply *original-foo* x y z)))
(setf (symbol-function 'foo) #'new-foo)
It's a good idea that for any of these variants, the function foo is
declaimed as notinline.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> you shouldn't touch it. ...
> you should most probably not touch it ...
> it's unlikely to be a good idea to touch it ...
That figures. :)
I think I'm going to put everything in a package. That way the nice
short names can be used everywhere except in external calls, and
the extra text in the calls is structured (my-pakg:foo) instead of
arbitrary character blobs (my-unique-foo-identifier).
Thanks for the help.
--
Dan
www.prairienet.org/~dsb
Dan Bensen <··········@cyberspace.net> writes:
> If the name you want to use for a CLOS method is already bound to an
> existing defun'd function. Is there a standard "best" alternative
> that people usually use? Should you define a package for it, or use a
> different name, or just do whatever works?
If it's a standard function (in the COMMON-LISP package), I'd try to
use a synonym.
Unless it's a rarely used CL function, in which case you could SHADOW
it, but this would be better done in a distinct package anyways, so
Using a distinct package for these generic functions is a good
solution.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
On 2007-02-20 20:15:11 +0000, Dan Bensen <··········@cyberspace.net> said:
> If the name you want to use for a CLOS method is already bound to an
> existing defun'd function. Is there a standard "best" alternative that
> people usually use? Should you define a package for it, or use a
> different name, or just do whatever works?
As others have said, you probably should not be redefining things that
are a standard part of CL unless they were designed to be redefined, or
you have a very good reason to want to do this. A good reason might be
to produce some compatible but extended functionality, a bad reason
would be because you want to grab the name for something unrelated,
like, say, overriding a bit shift operator to do, say I/O[*].
Some guy wrote a little library called conduits which exploits the
package system to let you do this in a fairly principled way: you can
define packages which are "like" other packages (in the sense of:
contain identical exported symbols) except for a few symbols. The
conduits system itself is an example of such a package, as it defines a
package which is "like" CL except that DEFPACKAGE & a couple of other
things are different. You can then use this package where you would
normally use CL.
--tim
[*] sorry
Dan Bensen <··········@cyberspace.net> writes:
> If the name you want to use for a CLOS method is already bound to an
> existing defun'd function. Is there a standard "best" alternative that
> people usually use? Should you define a package for it, or use a
> different name, or just do whatever works?
Having defined a package "MOTOR" which exports a symbol
"CAR", you can resolve the name clash in favour of the
CL:CAR. (with shadowing-import-from ???)
If members of an automobile association are represented as a
list of their name and their car one can define
(defun name (record)
(car record))
(defun motor:car (record)
(cadr record))
(defun copy-member (record)
(list (name record)
(motor:car record)))
which you could obfuscate as
(defun copy-member (record)
(list (car record)
(motor:car record))) ;-)
So you have motor:car playing the same role at the keyboard
as motor-car, except that you have the option of resolving
the symbol clash in favour of motor:car in some other
package, letting you abbreviate it to car.
I've never done this, it might be a rotten idea, but it
strikes me that, since one can use package qualifiers,
defining a package for it and using a different name are not
such distinct options as they initially appear to be.
Alan Crowe
Edinburgh
Scotland