This starts with an issue related to the choice
of a package prefix for printing, and ends with
a more general issue concerning user-defined
PRINT-OBJECT methods for standardised classes.
* * *
Often, a package's name is the `full name' and any
shorter forms are supplied as nicknames. On the
other hand, sometimes one wishes to have
vip:foo
instead of
very-important-package:foo
in the output.
Question #1: does ANSI CL require that the package _name_
(and not a nickname) must be used as the package prefix
when printing a symbol (and a package prefix must be
printed), or is this underspecified (as it appears to me)?
It appears that a typical implementation always uses
the package name (but I may need to be corrected). On
the other hand, the name and nicknames of a package
are completely equivalent as package prefixes as far
as the reader is concerned (unless I miss something,
and in the absence of renamings, of course).
Looking for ways to have some control over the choice
of the package prefix, I could think of the following:
(1) providing the package prefix that should be used
for output as the name, and the rest as nicknames;
not very nice since it is useful when the `main' package
name is more descriptive;
(2) defining a PRINT-OBJECT method for symbols which
chooses the appropriate package prefix among the name
and nicknames under programmer control.
(Some implementations might provide a hook, but I am
primarily interested in implementation-independent
solutions.)
Here we come to the question of specifying the appropriate
package prefix, and thus to the observation that perhaps
it would have been nice if PACKAGE was not a built-in
class (which cannot be subclassed). With built-in classes
like FIXNUM, there is no choice; but would it be so
hard for an implementation to define PACKAGE as
a `subclassable' class, so that I could say something
like
;; accessors, etc. omitted for simplicity
(defclass package-with-choice-of-prefix (package)
(prefix-of-choice))
and have the printing method use the prefix-of-choice
slot. Since I can't do that with a built-in class,
the chosen prefix must be stored in a separate data
structure (e.g. a hashtable indexed by package) which
is to me an inferior solution.
Now, more importantly, suggestion (2) above leads us
to a more general issue:
Question #2: how legal is it to define PRINT-OBJECT
methods on standardised classes?
It is neither explicitly allowed nor explicitly forbidden.
There is, however, explicit license for the user to
define PRINT-OBJECT methods for user-defined classes
which may be construed as an implicit restriction on
defining PRINT-OBJECT methods for standardised classes.
On the other hand, that works in at least a few implementations.
In my view, it would be nice if that restriction didn't
exist (if it isn't in my imagination only). I am sure everybody
could think of many examples and I'll give just one more
(besides the one with printing package prefixes). It was
an actual complaint by a colleague of mine that the
standard method for printing floats prints many more
digits than was actually necessary for his needs, and
(DEFMETHOD PRINT-OBJECT ((X FLOAT) S) ...) was a welcome
solution for him. (Note: I am aware that if a method
like that calls (e.g.) FORMAT, and thus there is a nested
invocation of the PRINT-OBJECT method, it must be ensured
that it then calls the next method.)
* * *
To sum up, I am suggesting that the user is allowed to
define PRINT-OBJECT methods on standardised classes (not
very hard?) and that certain built-in classes are `promoted'
to standard classes. The latter would be harder, perhaps much
harder; it also implies that it would be nice to make
(quite) a few ordinary functions generic (like RENAME-PACKAGE
for my particular case above). But isn't this a direction in
which it wouldn't hurt Common Lisp to move anyway?
Best regards,
Vassil.
"Vassil Nikolov" <········@math.acad.bg> writes:
> sometimes one wishes to have vip:foo
> instead of very-important-package:foo
> in the output.
>
> Question #1: ... is this underspecified ...?
Yes.
I'd like to see a (:prefix-name "VIP") possible in DEFPACKAGE.
I think Symbolics Genera has that option. Not being able to
control this is a serious pain.
> It appears that a typical implementation always uses
> the package name ...
Yeah, that's mostly what I've seen, too.
> On the other hand, the name and nicknames of a package
> are completely equivalent as package prefixes
You're right about this and this is unfortunate.
I personally tend to write my programs on the assumption that
longer names are more stable since they are less likely to
collide. In that regard, I'm quite happy about the package's
real (rather than nick-) name being used for printing if
*print-readably* is set, but I think for ordinary purposes
it's overkill and I'd rather offer a short name to use.
I'd also like FASL files to use the long name, so that
renaming the short name in the case of a symbol clash doesn't
hurt a compiled file. I tend to think of the short names as
"for use in interactive situations where convenient" but
"expendable".
Actually, in truth, I try to write my packages to never depend
at runtime on their name because I've been screwed by this
too many times. I prefer for both efficiency and robustness
to write:
(defvar *my-package* *package*)
and then use (intern whatever *my-package*) when needing to
refer to my own package.
> Looking for ways to have some control over the choice
> of the package prefix, I could think of the following:
>
> (1) providing the package prefix that should be used
> for output as the name, and the rest as nicknames;
> not very nice since it is useful when the `main' package
> name is more descriptive;
I think of the main package name as appropriate for use
in printing the package itself. e.g.,
*package* => #<Package "COMMON-LISP-USER">
> (2) defining a PRINT-OBJECT method for symbols which
> chooses the appropriate package prefix among the name
> and nicknames under programmer control.
If that's all it did, then I think you'd want to call it
something else than PRINT-OBJECT. Printing symbols is a
huge hassle and you don't want to duplicate all that a system
does in the PRINT-OBJECT method for symbols.
Also, as a rule, methods on symbols (or any other shared
type or name) are a bad idea since if two systems are loaded
that customize this, they will clobber each other. I prefer
a special variable control in that case so that co-resident
separate processes can each get their own desired behavior
without colliding.
> (Some implementations might provide a hook, but I am
> primarily interested in implementation-independent
> solutions.)
Ugh. I can understand this desire, but here you're stuck.
First, you can't customize methods on system types to begin
with, so you're not portable. Moreover, all the hair with
printing symbols including \ and | and appropriate uses of
case are REALLY hard to do--especially efficiently--so
good luck doing it portably!
> Question #2: how legal is it to define PRINT-OBJECT
> methods on standardised classes?
11.1.2.1.2 Constraints on the COMMON-LISP Package for
Conforming Programs
Except where explicitly allowed, the consequences are undefined
if any of the following actions are performed on an external
symbol of the COMMON-LISP package:
[....]
19. Defining a method for a standardized generic function which
is applicable when all of the arguments are direct instances
of standardized classes.
> It is neither explicitly allowed nor explicitly forbidden.
No, it's explicidtly disallowed unless permitted.
> There is, however, explicit license for the user to
> define PRINT-OBJECT methods for user-defined classes
> which may be construed as an implicit restriction on
> defining PRINT-OBJECT methods for standardised classes.
No, it's worse than that. It's explicitly construed as such, I think.
> On the other hand, that works in at least a few implementations.
That's true.
> In my view, it would be nice if that restriction didn't
> exist (if it isn't in my imagination only).
The reason for the restriction is that two systems with incompatible
desires will clash. Following the restriction tries to assure the
harmonious co-presence of two independently designed systems by
teaching them to make only "polite use" of shared resources.
For example, in a package FOO
(defmethod foo ((x symbol) (y frob)) ...)
causes no trouble because the dispatch on FROB makes this private to
the package FOO. Doing the same in package BAR will not result in a
collision because FOO::FROB and BAR::FROB are different. But
(defmethod foo ((x symbol) (y integer)) ...)
is not private because if done in package BAR, a collision will result
due to (EQ 'FOO::SYMBOL 'BAR::SYMBOL) and (EQ 'FOO::INTEGER 'BAR::INTEGER).
> I am sure everybody
> could think of many examples and I'll give just one more
> (besides the one with printing package prefixes).
The right fix is to convince implementors to install
(:PREFIX-NAME "VIP")
which is not as general as a print-object method but which
could eventually be proposed as part of a later standard.
> It was
> an actual complaint by a colleague of mine that the
> standard method for printing floats prints many more
> digits than was actually necessary for his needs, and
> (DEFMETHOD PRINT-OBJECT ((X FLOAT) S) ...) was a welcome
> solution for him.
But would collide with another application in the same environment
doing a different thing on the same signature.
> (Note: I am aware that if a method
> like that calls (e.g.) FORMAT, and thus there is a nested
> invocation of the PRINT-OBJECT method, it must be ensured
> that it then calls the next method.)
This is unfortunately not the only thing to worry about.
> To sum up, I am suggesting that the user is allowed to
> define PRINT-OBJECT methods on standardised classes (not
> very hard?) and that certain built-in classes are `promoted'
> to standard classes. The latter would be harder, perhaps much
> harder; it also implies that it would be nice to make
> (quite) a few ordinary functions generic (like RENAME-PACKAGE
> for my particular case above). But isn't this a direction in
> which it wouldn't hurt Common Lisp to move anyway?
If the hope is that programs will eventually compose to make more
interesting larger programs out of components, then I don't think
this is a good way for things to go.
On Fri, 15 May 1998 16:06:56 GMT,
Kent M Pitman <······@world.std.com> wrote:
>"Vassil Nikolov" <········@math.acad.bg> writes:
(...)
>I'd like to see a (:prefix-name "VIP") possible in DEFPACKAGE.
That will make me happy, especially if it is accompanied by
an accessor PACKAGE-PREFIX-NAME.
>I think Symbolics Genera has that option. Not being able to
^^^^^^^^^ I have never used one, to my regret, but from
what I have read it surely must be made by
intelligent people for intelligent people.
>control this is a serious pain.
(...)
>> On the other hand, the name and nicknames of a package
>> are completely equivalent as package prefixes
>
>You're right about this and this is unfortunate.
>
>I personally tend to write my programs on the assumption that
>longer names are more stable since they are less likely to
>collide. In that regard, I'm quite happy about the package's
>real (rather than nick-) name being used for printing if
>*print-readably* is set, but I think for ordinary purposes
>it's overkill and I'd rather offer a short name to use.
>I'd also like FASL files to use the long name, so that
>renaming the short name in the case of a symbol clash doesn't
>hurt a compiled file. I tend to think of the short names as
>"for use in interactive situations where convenient" but
>"expendable".
Maybe the designers of the name/nicknames approach had
something like that in mind but it never made it into
explicit language facilities. Perhaps it is worth at least
mentioning it when explaining packages (in Lisp books,
I mean).
>Actually, in truth, I try to write my packages to never depend
>at runtime on their name because I've been screwed by this
>too many times. I prefer for both efficiency and robustness
>to write:
>
> (defvar *my-package* *package*)
>
>and then use (intern whatever *my-package*) when needing to
>refer to my own package.
RENAME-PACKAGE is a mixed blessing, isn't it?
Thank you for the hint, will add it to my `programming
guidelines' box.
(...)
>> (2) defining a PRINT-OBJECT method for symbols which
>> chooses the appropriate package prefix among the name
>> and nicknames under programmer control.
>
>If that's all it did, then I think you'd want to call it
>something else than PRINT-OBJECT. Printing symbols is a
>huge hassle and you don't want to duplicate all that a system
>does in the PRINT-OBJECT method for symbols.
The PRINT-OBJECT method for symbols was the only thing
that came to my mind as the place to customise printing
the package prefix.
(...)
>Ugh. I can understand this desire, but here you're stuck.
>First, you can't customize methods on system types to begin
>with, so you're not portable. Moreover, all the hair with
>printing symbols including \ and | and appropriate uses of
>case are REALLY hard to do--especially efficiently--so
>good luck doing it portably!
No, I definitely am not strong enough to do all that myself.
I was more thinking along the following lines:
* determine the package prefix to use, then call the system
method for printing symbols, arranging for the prefix
to be treated as a symbol in the current package;
* print ":" or "::" as appropriate
(I need to check if any changes to the readtable
might interfere with the usage of colons here);
* use the system method to print the symbol name, again
arranging for it to be treated as if its package is the
current one.
(I admit this is a kludge presented by handwaiving. But
I guess that is a minor offense in this case since adding
a method for a standardised class is illegal anyway.)
>> Question #2: how legal is it to define PRINT-OBJECT
>> methods on standardised classes?
>
> 11.1.2.1.2 Constraints on the COMMON-LISP Package for
> Conforming Programs
>
> Except where explicitly allowed, the consequences are undefined
> if any of the following actions are performed on an external
> symbol of the COMMON-LISP package:
> [....]
> 19. Defining a method for a standardized generic function which
> is applicable when all of the arguments are direct instances
> of standardized classes.
>
>> It is neither explicitly allowed nor explicitly forbidden.
>
>No, it's explicidtly disallowed unless permitted.
My mistake. I must read the HM more carefully next time.
(H stands for Hyper.)
(...)
>The reason for the restriction is that two systems with incompatible
>desires will clash. Following the restriction tries to assure the
>harmonious co-presence of two independently designed systems by
>teaching them to make only "polite use" of shared resources.
>For example, in a package FOO
> (defmethod foo ((x symbol) (y frob)) ...)
>causes no trouble because the dispatch on FROB makes this private to
>the package FOO. Doing the same in package BAR will not result in a
>collision because FOO::FROB and BAR::FROB are different. But
> (defmethod foo ((x symbol) (y integer)) ...)
>is not private because if done in package BAR, a collision will result
>due to (EQ 'FOO::SYMBOL 'BAR::SYMBOL) and (EQ 'FOO::INTEGER 'BAR::INTEGER).
>
(...)
>If the hope is that programs will eventually compose to make more
>interesting larger programs out of components, then I don't think
>this is a good way for things to go.
I will still make an attempt to reconcile your point with mine,
though, ceteris paribus, your point is stronger. (Independently
of what the standard allows.)
Let's assume the model of composing programs (program modules,
whatever you may call them) that consists of these three layers:
user layer
library layer
system layer
(the names are probably not the best ones). There is nothing
below the system layer which provides the basic functionality;
this is e.g. a Common Lisp implementation. The library layer
builds on top of the system layer and together with it provides
components for contructing the programs of the user layer.
A characteristic feature of user layer components is that
they will not be used by anything built on top of them (otherwise
they belong to the library layer).
Now, the makers of the system layer are not restricted by
anything (except by the requirement to produce useful functionality).
The components of the library layer are subject to many restrictions
that either arise from the nature of the system layer or from
the need to ensure coexistence of several of those components
when they are used in one and the same user level program.
Since, however, a user layer program is at the top, it may afford to
disobey some of the restrictions that are necessarily imposed on
library layer stuff to make it viable. For example (disregarding
the legality of this), a PRINT-OBJECT method for FLOATs that
is part of a library module would clash with other library modules
that do the same so we disallow this for all library modules.
But the user module is the `master' so it may get different
treatment. (The user layer, like Mount Olympus, is at the top,
so Jove may do things that the oxen in the library can't do.)
Sometimes, indeed, a user module may evolve into a library
module, and to be admitted there it would have to pass a more
stringent test. But sometimes we have just a single user program
and other things are more important so we may be willing to
sacrifice the option of combining it with others. (I realise now
I have made for yet another time the conclusion that
`all the world's a tradeoff, and all the men and women
merely victims of the three laws of thermodynamics.')
Best regards,
Vassil.
In article <··························@nym.alias.net>,
Vassil Nikolov <········@math.acad.bg> wrote:
>Since, however, a user layer program is at the top, it may afford to
>disobey some of the restrictions that are necessarily imposed on
>library layer stuff to make it viable. For example (disregarding
>the legality of this), a PRINT-OBJECT method for FLOATs that
>is part of a library module would clash with other library modules
>that do the same so we disallow this for all library modules.
>But the user module is the `master' so it may get different
>treatment. (The user layer, like Mount Olympus, is at the top,
>so Jove may do things that the oxen in the library can't do.)
This is not true.
First of all, there may be multiple user layer programs. For instance, a
single GNU Emacs session can load in lots of packages that I think would be
considered user layer: RMAIL, GNUS, Calendar, etc. If each one thought it
could define its own PRINT-OBJECT method for FLOATs (assume for this
discussion that GNU Emacs were written in Common Lisp), you would have a
conflict.
Also see my post where I mentioned that the system layer may depend on
undocumented aspects of its own implementation, and if you replace those
functions with your own they will likely support these dependences.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
On Sun, 17 May 1998 08:13:08 GMT,
Barry Margolin <······@bbnplanet.com> wrote:
>In article <··························@nym.alias.net>,
>Vassil Nikolov <········@math.acad.bg> wrote:
>>Since, however, a user layer program is at the top, it may afford to
>>disobey some of the restrictions that are necessarily imposed on
>>library layer stuff to make it viable. For example (disregarding
>>the legality of this), a PRINT-OBJECT method for FLOATs that
>>is part of a library module would clash with other library modules
>>that do the same so we disallow this for all library modules.
>>But the user module is the `master' so it may get different
>>treatment. (The user layer, like Mount Olympus, is at the top,
>>so Jove may do things that the oxen in the library can't do.)
>
>This is not true.
>
>First of all, there may be multiple user layer programs. For instance, a
>single GNU Emacs session can load in lots of packages that I think would be
>considered user layer: RMAIL, GNUS, Calendar, etc. If each one thought it
>could define its own PRINT-OBJECT method for FLOATs (assume for this
>discussion that GNU Emacs were written in Common Lisp), you would have a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I would be happy with that not only for this discussion...
>conflict.
But sometimes there is a single user layer program, and I am
thinking about the case when the programmer has control over
that. (Either when the user and programmer are one and the
same person, or when it is documented that a certain program may
be used alone. That might make it less valuable, but sometimes
that doesn't matter so much.)
Further, it appears to me that Common Lisp itself is not
absolutely consistent with regards to preventing clashes
between programming modules. While I cannot define
PRINT-OBJECT methods for standardised classes, I can
change the values of *PRINT-xxx* variables that affect
in quite a few ways printing of standardised classes
(instances thereof). Each module can set those variables
to different values so you could easily have a clash here.
(Well, with PRINT-OBJECT methods clashes become more
spectacular.)
As I mentioned in my other post (I hope both of them make
it through my losing Internet connection), allowing
user-defined PRINT-OBJECT methods appears to me a more
elegant solution rather than introducing something
like *PRINT-FLOAT-FORMAT* (assuming that the desire
to request that #(1.23 4.56 7.89) is printed instead of
#(1.231234567 4.563214562 7.891472586) is accepted
as reasonable).
Another thought comes into my head: would it help with clashes
if there was something like METHOD-FLET and METHOD-LABELS?
This has just occurred to me, so I haven't thought in more
detail if it is actually meaningful to talk about methods
to a global generic function that have a limited scope,
but maybe someone has already worked on that or is working
now on it? Perhaps we don't actually need lexical scoping
on methods but some other way to limit their availability
to just that programming module that uses them so clashes
between modules are avoided. This appears similar to
the difference between shallow and deep binding with
regard to multiple processes sharing or not sharing
bindings of special variables. What we now have with
DEFMETHOD is like shallow binding; what about an analogue
to deep binding?
>Also see my post where I mentioned that the system layer may depend on
>undocumented aspects of its own implementation, and if you replace those
>functions with your own they will likely support these dependences.
As I wrote, I am thinking about responsible programmers.
Besides, I don't really want to replace, but rather to
augment. (This doesn't solve the problem, just show
my attitude.)
Best regards,
Vassil.
In article <·····················@banmatpc.math.acad.bg>,
Vassil Nikolov <········@math.acad.bg> wrote:
>Further, it appears to me that Common Lisp itself is not
>absolutely consistent with regards to preventing clashes
>between programming modules. While I cannot define
>PRINT-OBJECT methods for standardised classes, I can
>change the values of *PRINT-xxx* variables that affect
>in quite a few ways printing of standardised classes
>(instances thereof). Each module can set those variables
>to different values so you could easily have a clash here.
>(Well, with PRINT-OBJECT methods clashes become more
>spectacular.)
This is true. It's a compromise, since the *PRINT-xxx* variables are
intended to correspond to user preferences. WITH-STANDARD-IO-BINDINGS was
then created so that applications that depend on consistent output
formatting could get it when necessary, regardless of what the user has
done.
>Another thought comes into my head: would it help with clashes
>if there was something like METHOD-FLET and METHOD-LABELS?
The original CLOS specification had GENERIC-FLET and GENERIC-LABELS, but
they were removed for a number of reasons. They were hard to implement,
and I don't think we could come up with many good uses of them.
>>Also see my post where I mentioned that the system layer may depend on
>>undocumented aspects of its own implementation, and if you replace those
>>functions with your own they will likely support these dependences.
>
>As I wrote, I am thinking about responsible programmers.
>Besides, I don't really want to replace, but rather to
>augment. (This doesn't solve the problem, just show
>my attitude.)
It has nothing to do with responsibility -- you simply can't know what the
implementation has done. What if your augmentation calls a function that
(unbeknownst to you) calls the generic function you're modifying? This
would result in infinite recursion.
If CL were layered into primitives and higher-level libraries, such that
primitives were guaranteed not to use anything in the library layer, you
might be able to achieve what you want if your augmentations only used
primitives.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
On Tue, 19 May 1998 03:25:01 GMT,
Barry Margolin <······@bbnplanet.com> wrote:
>In article <·····················@banmatpc.math.acad.bg>,
>Vassil Nikolov <········@math.acad.bg> wrote:
(...)
>>Another thought comes into my head: would it help with clashes
>>if there was something like METHOD-FLET and METHOD-LABELS?
>
>The original CLOS specification had GENERIC-FLET and GENERIC-LABELS, but
>they were removed for a number of reasons. They were hard to implement,
>and I don't think we could come up with many good uses of them.
METHOD-FLET would be quite different from GENERIC-FLET.
But I have to see if I am not actually thinking about
WITH-ADDED-METHODS or something along those lines.
>It has nothing to do with responsibility -- you simply can't know what the
>implementation has done. What if your augmentation calls a function that
>(unbeknownst to you) calls the generic function you're modifying? This
>would result in infinite recursion.
In many cases this can be prevented by having my augmenting
method just call the next method if it is re-entered. Well,
I guess that's a kludge.
>If CL were layered into primitives and higher-level libraries, such that
>primitives were guaranteed not to use anything in the library layer, you
>might be able to achieve what you want if your augmentations only used
>primitives.
That would be nice; but the standardisation committee has a lot
of other work at its hands...
Best regards,
Vassil.
"Vassil Nikolov" <········@math.acad.bg> writes:
> That would be nice; but the standardisation committee has a lot
> of other work at its hands...
What "standardization committee"?
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
On 03 Jun 1998 10:00:22 +0200,
Marco Antoniotti <·······@galvani.parades.rm.cnr.it> wrote:
>"Vassil Nikolov" <········@math.acad.bg> writes:
>
>> That would be nice; but the standardisation committee has a lot
>> of other work at its hands...
>
>What "standardization committee"?
Any standardisation committee...
If you mean that there is no standing Common Lisp
standardisation committee, OK, please understand
my words as follows: `at any point in time, whenever
a Common Lisp standardisation committee exists, it
has a lot of work on its hands.'
Vale,
Vassil.
In article <··························@nym.alias.net>,
"Vassil Nikolov" <········@math.acad.bg> writes:
>
> On Fri, 15 May 1998 16:06:56 GMT,
> Kent M Pitman <······@world.std.com> wrote:
>
>>"Vassil Nikolov" <········@math.acad.bg> writes:
> (...)
>>I'd like to see a (:prefix-name "VIP") possible in DEFPACKAGE.
>
> That will make me happy, especially if it is accompanied by
> an accessor PACKAGE-PREFIX-NAME.
>
>>I think Symbolics Genera has that option. Not being able to
If I remember correctly, it was called :short-name. The SYSTEMS-INTERNAL
package, for instance, had a short name of SI.
> ^^^^^^^^^ I have never used one, to my regret, but from
> what I have read it surely must be made by
> intelligent people for intelligent people.
>>control this is a serious pain.
What? You don't like "Systems for Dummies"? I'm flabbergasted! :-)
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> > That will make me happy, especially if it is accompanied by
> > an accessor PACKAGE-PREFIX-NAME.
> >
> >>I think Symbolics Genera has that option. Not being able to
>
> If I remember correctly, it was called :short-name. The SYSTEMS-INTERNAL
> package, for instance, had a short name of SI.
FWIW, I checked. (Easy to do, since I have a Macivory in my living
room.) It's called SI:PKG-PREFIX-NAME in Zetalisp; there is no
corresponding SCL:PACKAGE-PREFIX-NAME, but I'm sure that's just an
oversight. Genera's extended forms of DEFSYSTEM and MAKE-PACKAGE both
take :PREFIX-NAME arguments. There is no short-name concept for
packages in Genera.
(si:pkg-prefix-name (find-package "SI")) => "SI"
(si:pkg-name (find-package "SI")) => "SYSTEM-INTERNALS"
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> > That will make me happy, especially if it is accompanied by
>> > an accessor PACKAGE-PREFIX-NAME.
>> >
>> >>I think Symbolics Genera has that option. Not being able to
>>
>> If I remember correctly, it was called :short-name. The SYSTEMS-INTERNAL
>> package, for instance, had a short name of SI.
>
> FWIW, I checked. (Easy to do, since I have a Macivory in my living
> room.) It's called SI:PKG-PREFIX-NAME in Zetalisp; there is no
> corresponding SCL:PACKAGE-PREFIX-NAME, but I'm sure that's just an
> oversight. Genera's extended forms of DEFSYSTEM and MAKE-PACKAGE both
> take :PREFIX-NAME arguments. There is no short-name concept for
> packages in Genera.
>
> (si:pkg-prefix-name (find-package "SI")) => "SI"
> (si:pkg-name (find-package "SI")) => "SYSTEM-INTERNALS"
>
I goofed. Short-name was a property on a host in the namespace db, along
with pretty-name. Brain rot! That's what happens when you have to use unix
machines for too long.
Mike McDonald
·······@mikemac.com
From: Steven M. Haflich
Subject: Re: package prefixes; PRINT-OBJECT methods
Date:
Message-ID: <3560BD64.37EAE320@franz.com>
Kent M Pitman wrote:
> "Vassil Nikolov" <········@math.acad.bg> writes:
>
> > sometimes one wishes to have vip:foo
> > instead of very-important-package:foo
> > in the output.
>
> I'd like to see a (:prefix-name "VIP") possible in DEFPACKAGE.
> I think Symbolics Genera has that option. Not being able to
> control this is a serious pain.
>
Long long ago I addressed this issue in Allegro by adding another
printercontrol special variable, *PRINT-NICKNAME*. If true, when the printer
prints a package-qualified symbol it uses the first package nickname, if there
is one, rather than the package name. I agree with Kent's preference that fasl
and other machine-readable text should use full package names. The motivation
for this extension was primarily for use in human-readable programming-tool
output
where printing full package names consumes too much screen real estate. The
programmer would rather have a profiler or backtrace print USER::FOO than
COMMON-LISP-USER::FOO, and there is little chance for confusion.
> > Question #2: how legal is it to define PRINT-OBJECT
> > methods on standardised classes?
>
> No, it's explicidtly disallowed unless permitted.
>
Agreed, it is not portably legal to redefine PRINT-OBJECT on anysystem
classes. (You could define a method specialized on the
class of the second argument, if there were a portable way to specialize
streams...) But everyone seems to have missed the standard language
mechanism that supports print customization: Copy the pretty print
dispatch table, customize the method for SYMBOL, and lambda bind
*PRINT-PPRINT-DISPATCH* (and, of course, *PRINT-PRETTY*)
when you want that method in effect.
However, I agree with Kent that printing symbols correctly is a large
task and it would be unfortunate to have to duplicate so much tedius
machinery.
> The right fix is to convince implementors to install
> (:PREFIX-NAME "VIP")
> which is not as general as a print-object method but which
> could eventually be proposed as part of a later standard.
Sounds fine to me.
On Mon, 18 May 1998 15:59:48 -0700,
Steven M. Haflich <···@franz.com> wrote:
>Long long ago I addressed this issue in Allegro by adding another
>printercontrol special variable, *PRINT-NICKNAME*. If true, when the printer
>prints a package-qualified symbol it uses the first package nickname, if there
>is one, rather than the package name.
This gives a solution for this particular issue.
As I wrote, I believe IWBN to have a language that
allows the programmer to define such a solution,
and/or solutions for the multitude of other problems
of this type, if and when such solutions become
needed. Otherwise, how many *PRINT-xxx* variables
could we have?
(...)
>Agreed, it is not portably legal to redefine PRINT-OBJECT on anysystem
>classes. (You could define a method specialized on the
>class of the second argument, if there were a portable way to specialize
But the second argument is very often not the actual stream,
but some internal one.
>streams...) But everyone seems to have missed the standard language
>mechanism that supports print customization: Copy the pretty print
>dispatch table, customize the method for SYMBOL, and lambda bind
>*PRINT-PPRINT-DISPATCH* (and, of course, *PRINT-PRETTY*)
>when you want that method in effect.
I don't know about everyone, but I *did* miss it.
It's not exactly the same as PRINT-OBJECT, but sufficiently
close---and legal!
(...)
Best regards,
Vassil.
From: Howard R. Stearns
Subject: Re: package prefixes; PRINT-OBJECT methods
Date:
Message-ID: <3562F4E9.62E4@elwood.com>
Did I miss something? Has no one mentioned PPRINT-DISPATCH?
Rather than defining print-object, can't you define your own (or muck up
the standard) *print-pprint-dispatch* table with whatever behavior you
want for objects of type SYMBOL, DOUBLE-FLOAT, etc.
In article <··························@nym.alias.net>,
Vassil Nikolov <········@math.acad.bg> wrote:
>Here we come to the question of specifying the appropriate
>package prefix, and thus to the observation that perhaps
>it would have been nice if PACKAGE was not a built-in
>class (which cannot be subclassed).
Allowing users to subclass standard classes opens up a very large can of
worms. Implementations often depend on undocumented details of their own
implementations, but if the user can override these by subclassing and then
shadowing the implementator's methods he can cause the system to misbehave.
This is one of the reasons why users aren't allowed to redefine standard
functions, either (the other reason is because multiple applications trying
to redefine the same function will mess each other up -- the same
explanation Kent gave for why users aren't allowed to define methods for
standard GF's on standard classes).
It can be done, and some languages provide it to some extent, but it's then
necessary to specify lots of protocols and requirements, and require the
implementation to be tolerant of users overriding methods. Had we
considered doing this for CL, I suspect it would have postponed completion
of the ANSI standard by at least a year.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
On Fri, 15 May 1998 19:09:31 GMT,
Barry Margolin <······@bbnplanet.com> wrote:
>In article <··························@nym.alias.net>,
>Vassil Nikolov <········@math.acad.bg> wrote:
>>Here we come to the question of specifying the appropriate
>>package prefix, and thus to the observation that perhaps
>>it would have been nice if PACKAGE was not a built-in
>>class (which cannot be subclassed).
>
>Allowing users to subclass standard classes opens up a very large can of
^^^^^^^^
You actually mean standardised classes,
don't you? (I don't mean to criticise
you, just to make sure there is no confusion.)
>worms. Implementations often depend on undocumented details of their own
Yes, it's worth to open it only if you fish a lot and have hooks
for all the worms...
>implementations, but if the user can override these by subclassing and then
>shadowing the implementator's methods he can cause the system to misbehave.
>This is one of the reasons why users aren't allowed to redefine standard
>functions, either (the other reason is because multiple applications trying
>to redefine the same function will mess each other up -- the same
>explanation Kent gave for why users aren't allowed to define methods for
>standard GF's on standard classes).
>
>It can be done, and some languages provide it to some extent, but it's then
>necessary to specify lots of protocols and requirements, and require the
>implementation to be tolerant of users overriding methods. Had we
>considered doing this for CL, I suspect it would have postponed completion
>of the ANSI standard by at least a year.
I should have written that it would be nice if more standardised
classes were `subclassable' *only* if the price to pay was
reasonable. Postponing the standard for a year (even a month,
say) would be too high a price. I was actually thinking of
moving towards more freedom in subclassing in the _future_,
perhaps after CL has a standardised MOP, and surely after
the Lisp community has developed an agreement on how to do it.
Perhaps a small and not very dangerous step in that direction
might be relaxing the prohibition on subclassing by
giving implementations license to document how
a given standardised classes can be subclassed
(at the expense of portability, of course, but that
would at least allow users to experiment). For example,
how (un)reasonable would it be to leave it unspecified
in (a future revision of) the standard whether certain
standardised classes (e.g., PACKAGE) are built-in classes
or standard classes?
Why am I concerned with that? Not merely to get more
freedom. If I take the package prefix example again,
this particular functionality can be provided by
an extension to ANSI CL that gives you something like
a PACKAGE-PREFIX-NAME accessor (the value that it accesses
defaults to the package name) and the rule that this
value is used when printing a package prefix. Not very
difficult to do, but if this is part of the standard,
every implementation would have to do it while few
programmers will ever use it. There are more than
enough such features in CL already, and in my opinion
it would be better to avoid adding more of this type.
It would be more difficult, but perhaps better for
the language in the long run, if instead of satisfying
every programmer's particular need explicitly there
is a way for them to do it themselves (yes, I am thinking
about responsible programmers here, but are they so
rare in the Lisp domain?).
As regards the conflicts between multiple applications,
I'll respond to your other post as well and mention
that issue there.
Best regards,
Vassil.
In article <·····················@banmatpc.math.acad.bg>,
Vassil Nikolov <········@math.acad.bg> wrote:
>Perhaps a small and not very dangerous step in that direction
>might be relaxing the prohibition on subclassing by
>giving implementations license to document how
>a given standardised classes can be subclassed
>(at the expense of portability, of course, but that
>would at least allow users to experiment). For example,
>how (un)reasonable would it be to leave it unspecified
>in (a future revision of) the standard whether certain
>standardised classes (e.g., PACKAGE) are built-in classes
>or standard classes?
Implementations can already do this as an extension. They can do almost
anything they want, so long as it doesn't change the behavior of conforming
programs. Every place where the standard says "the consequences are
undefined", an implementation is permitted to define it. It doesn't mean
you're not allowed to do it, and it doesn't require implementations to
signal an error, it just means that you can't do it portably, since the
standard doesn't say what it means.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
On Tue, 19 May 1998 03:30:17 GMT,
Barry Margolin <······@bbnplanet.com> wrote:
>In article <·····················@banmatpc.math.acad.bg>,
>Vassil Nikolov <········@math.acad.bg> wrote:
>>Perhaps a small and not very dangerous step in that direction
>>might be relaxing the prohibition on subclassing by
>>giving implementations license to document how
>>a given standardised classes can be subclassed
>>(at the expense of portability, of course, but that
>>would at least allow users to experiment). For example,
>>how (un)reasonable would it be to leave it unspecified
>>in (a future revision of) the standard whether certain
>>standardised classes (e.g., PACKAGE) are built-in classes
>>or standard classes?
>
>Implementations can already do this as an extension. They can do almost
>anything they want, so long as it doesn't change the behavior of conforming
>programs. Every place where the standard says "the consequences are
>undefined", an implementation is permitted to define it. It doesn't mean
>you're not allowed to do it, and it doesn't require implementations to
>signal an error, it just means that you can't do it portably, since the
>standard doesn't say what it means.
To decrease the number of loose ends:
I incorrectly believed that the standard said all classes
that correspond to standardise types (like PACKAGE) are
built-in classes. In fact, it is _implementation_dependent_
whether they are built-in classes or some other classes
(CLHS 4.3.8.1 or thereabouts). So the standard already
gives what I was asking for, and it is up to the
implementors to find it advisable for classes like PACKAGE
to be standard classes.
Otherwise, the effects of using a built-in class as a superclass
in a DEFCLASS form are not undefined: an error is signalled.
By the way, let's return once again to augmenting PRINT-OBJECT.
The solution to use the pretty print dispatch table is the thing
to do in many cases, but I still believe that having more functionality
will be helpful. Perhaps this would be appropriate: introduce
a *PRINT-OBJECT* (or *PRINT-OBJECT-HOOK*) variable whose
initial value is #'PRINT-OBJECT and instead of requiring
WRITE, PRINT, etc. call PRINT-OBJECT, make them call the
function that is the value of *PRINT-OBJECT*. Naturally,
WITH-STANDARD-IO-SYNTAX binds that one too. Just another
item on the wish list...
Best regards,
Vassil.