(package-name "not a name") -> type-error or package-error?
Sam Steingold
(progn (ignore-errors (delete-package "not a name"))
(package-name "not a name"))
signal? CMUCL signals type-error, ACL and CLISP signal package-error.
CLHS says that it should be type-error when the argument is not a
package designator, and the glossary entry for the latter ("object that
denotes a package" as opposed to "object that _CAN_ denote a package")
appears to imply that "CL" _IS_ a package designator because "CL" is a
nickname for the "COMMON-LISP" package, while "not a name" may or may
not be a package designator depending on the state of the system (i.e.,
whether "not a name" has been made the name or a nickname of a valid
package).
What do people think?
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Why use Windows, when there are Doors?
Nils Goesche
> what error should
>
> (progn (ignore-errors (delete-package "not a name"))
> (package-name "not a name"))
>
> signal? CMUCL signals type-error, ACL and CLISP signal package-error.
>
> CLHS says that it should be type-error when the argument is not a
> package designator, and the glossary entry for the latter ("object that
> denotes a package" as opposed to "object that _CAN_ denote a package")
> appears to imply that "CL" _IS_ a package designator because "CL" is a
> nickname for the "COMMON-LISP" package, while "not a name" may or may
> not be a package designator depending on the state of the system (i.e.,
> whether "not a name" has been made the name or a nickname of a valid
> package).
>
> What do people think?
Heh, tricky. Both PACKAGE-ERROR and TYPE-ERROR seem reasonable.
Couldn't you derive a condition-type from both of them?
PACKAGE-ERROR's :PACKAGE initialization argument accepts a
package designator, so this should be doable, I think.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
JP Massar
>what error should
>
>(progn (ignore-errors (delete-package "not a name"))
> (package-name "not a name"))
>
>signal? CMUCL signals type-error, ACL and CLISP signal package-error.
>
>CLHS says that it should be type-error when the argument is not a
>package designator, and the glossary entry for the latter ("object that
>denotes a package" as opposed to "object that _CAN_ denote a package")
>appears to imply that "CL" _IS_ a package designator because "CL" is a
>nickname for the "COMMON-LISP" package, while "not a name" may or may
>not be a package designator depending on the state of the system (i.e.,
>whether "not a name" has been made the name or a nickname of a valid
>package).
>
>What do people think?
>
ACL signals a package error regardless
(package-name 5) --> package error
which seems to be incorrect according to the HS.
I would say that if no package object can be obtained
from the argument via permissable means the most
reasonable interpretation of the HS is that a type error
should be signalled.
However, it would have been more appropriate to say that
a package error should be signalled if the argument is
a string designator and no package by that name can be
found, while a type error should be signalled if the
argument is neither a string designator nor a package object.
Christophe Rhodes
> On Fri, 01 Nov 2002 22:14:38 GMT, Sam Steingold <s...@gnu.org> wrote:
> [ package-error/type-error ]
> >What do people think?
> I would say that if no package object can be obtained
> from the argument via permissable means the most
> reasonable interpretation of the HS is that a type error
> should be signalled.
>
> However, it would have been more appropriate to say that
> a package error should be signalled if the argument is
> a string designator and no package by that name can be
> found, while a type error should be signalled if the
> argument is neither a string designator nor a package object.
I'm of the opinion that this latter interpretation is the most
sensible, with the caveat that I agree that the spec is not strictly
behind my interpretation.
The difference between this and pathname designators is that, when a
pathname designator such as a string is used to designate a
nonexistent pathname, this pathname is created; the same mental model
for what happens when "NOT-A-PACKAGE-NAME" is passed to a package
function doesn't work; in a sense, the extra level of indirection to
the filesystem acts as a clear separator.
That said, throwing a type-error on "name for non-existent package"
doesn't make an enormous amount of sense to me; absent SATISFIES,
there's nothing you can feed to :EXPECTED-TYPE of the type error;
worse, an implementation is not required to recognize that
(subtypep '(member "CL") '(satisfies package-designator-p))
is T, T; so there's no way of interrogating the system on the question
"will I get a type-error if I ask for this to happen?"
Can anyone who was there, as it were, comment on this oddness of the
behaviour of package designators? Is there a reason for this that I'm
missing?
Cheers,
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Erik Naggum
| what error should
|
| (progn (ignore-errors (delete-package "not a name"))
| (package-name "not a name"))
|
| signal?
As usual, you have conflated several issues and made yourself a knot.
There are several independent questions here:
When (find-package foo) returns nil for some foo, what should
(package-name foo) return or signal?
When a package has been deleted, should the name still hang around
somehow?
When a package designator is not a name, what signal should package
functions signal?
From this confusing mess, let me assume that you really want to ask what
(package-name foo) should do when (find-package foo) returns nil because
foo is a string and not a package.
| CLHS says that it should be type-error when the argument is not a package
| designator,
This means that if you give any package-function something other than a
string or a package, you get a type error. Since you give the function a
string, you have given it a package designator and /this/ particular
reason to signal a type error is therefore not invoked.
| ("object that denotes a package" as opposed to "object that _CAN_ denote
| a package")
No other designators "can" denote anything, so this is one of those cases
where a reader has to invent something in order to make a clear text
confusing. The designator is a type convention, not a value convention,
which it seems you want it to be and which confuses you greatly.
| appears to imply that "CL" _IS_ a package designator because "CL" is a
| nickname for the "COMMON-LISP" package, while "not a name" may or may not
| be a package designator depending on the state of the system (i.e.,
| whether "not a name" has been made the name or a nickname of a valid
| package).
This is simply horribly confused.
| What do people think?
I think you should think more /clearly/ about what you want to know.
In this case, I /assume/ we have a question of what to do when a package
designator does not resolve to a package. That is (find-package foo)
returns nil, and foo is "not a name", which is at horribly stupid string
to use in an example because it confuses semantic levels. It /is/ a name
by virtue of being a string. It is not the name of an existing package,
but that does not mean it is not a name. This confusion just adds to
your problems.
So, what should (package-name (find-package foo)) do when the inner
function returns nil? Do we have to go through another step to make this
clear in this horrible confusion? Well, let me do that, just in case.
A designator has a means to resolve into the desired type, let us call
that the designator-resolver function. A call to a function that accepts
a designator for a type foo that is of type bar, will therefore have the
form (function-call bar-value) which is in effect the same as the much
less convenient (function-call (designator-resolver bar-value)). We do,
in fact, have to assume that the function calls designator-resolver when
given a designator.
Now, the points of departure should finally be pretty obvious.
Should the designator-resolver for package designators return a
type-error if it receives a designator for a package that does not exist
or is deleted? My answer is a resounding "no". The reason for this is
that package designators are used when /creating/ packages, too.
Should the expression (package-name foo) be /identical/ to the similar
expression (package-name (find-package foo)) in all possible respects?
My answer is a resounding "yes". The reason for this is that the cases
where it is not would be horribly confusing and messy.น
Now, please note the exceptionally beautiful nature of designator-resolver
functions such as find-package: they actually take the same type they are
intended to return. (find-package (find-package "CL")) not only works,
it is /intended/ to work, just as (string (string #\a)) does.
So, if we for the moment ignore package designators, what should
(package-name nil) do? This is not an error with the package because
there is no package, this is an error with the type of the argument, a
type-error.
I assumed that you do not want to confuse this issue with the spurious
delete-package, but that this redundant form was only to ensure that
(find-package "not a name") would return nil. I have also assumed that
"not a name" is just a string like every other string and not some random
noise that is not a string. If these assumptions are incorrect, please
clarify your question and remove superfluous redundancies.
-------
น There /is/ one such case that makes things needlessly messy, though.
(defpackage "NIL") and have fun.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Paul F. Dietz
> | CLHS says that it should be type-error when the argument is not a package
> | designator,
>
> This means that if you give any package-function something other than a
> string or a package, you get a type error.
Characters and symbols are also string designators, and therefore are
package designators as well.
Paul
Sam Steingold
> * On the subject of "Re: (package-name "not a name") -> type-error or package-error?"
> * Sent on 02 Nov 2002 14:33:59 +0000
> * Honorable Erik Naggum <er...@naggum.no> writes:
>
> | appears to imply that "CL" _IS_ a package designator because "CL" is a
> | nickname for the "COMMON-LISP" package, while "not a name" may or may not
> | be a package designator depending on the state of the system (i.e.,
> | whether "not a name" has been made the name or a nickname of a valid
> | package).
>
> This is simply horribly confused.
good - it was intended to look that way because this was the only
reasoning for a type-error I could think of.
> Should the designator-resolver for package designators return a
> type-error if it receives a designator for a package that does not exist
> or is deleted? My answer is a resounding "no".
sure
> Should the expression (package-name foo) be /identical/ to the similar
> expression (package-name (find-package foo)) in all possible respects?
> My answer is a resounding "yes".
sure
> So, if we for the moment ignore package designators, what should
> (package-name nil) do? This is not an error with the package because
> there is no package, this is an error with the type of the argument, a
> type-error.
huh?! NIL, a symbol, _is_ a package designator!
it just does not (usually) designate any package.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
In every non-trivial program there is at least one bug.
Erik Naggum
| So, if we for the moment ignore package designators, what should
| (package-name nil) do? This is not an error with the package because
| there is no package, this is an error with the type of the argument, a
| type-error.
* Sam Steingold
| huh?! NIL, a symbol, _is_ a package designator!
| it just does not (usually) designate any package.
I think the meaning of "if we for the moment ignore package designators"
is sufficiently clear.
You may not have noticed the footnote that covered that particular case.
My general aim in my communication is precision and clarity. In this
particular case, it was the specific goal of my article to be very precise
and very clear. Frankly, I get annoyed when someone who asks a question
shows so much disrespect for me and my effort to help them that they fail
to read what I have written with anything less than their full attention.
Specifications should be read with care and one's full attention, too.
Sam Steingold
> * On the subject of "Re: (package-name "not a name") -> type-error or package-error?"
> | So, if we for the moment ignore package designators, what should
> | (package-name nil) do? This is not an error with the package because
> | there is no package, this is an error with the type of the argument, a
> | type-error.
>
> * Sam Steingold
> | huh?! NIL, a symbol, _is_ a package designator!
> | it just does not (usually) designate any package.
>
> I think the meaning of "if we for the moment ignore package designators"
> is sufficiently clear.
Then what was the point of your above remark?
If we "ignore package designators", the situation is trivial: if the
argument to PACKAGE-NAME is not a PACKAGE, it is a TYPE-ERROR.
So, what if we do _not_ ignore package designators?
The two paragraphs that I quoted and you elided from my reply appear to
imply that your answer to my question is PACKAGE-ERROR, not TYPE-ERROR.
Let me repeat my question with "precision and clarity":
What should the error type of
(package-name "string which does not name any existing package")
be?
> You may not have noticed the footnote that covered that particular case.
I did.
> My general aim in my communication is precision and clarity. In
> this particular case, it was the specific goal of my article to be
> very precise and very clear.
You missed your general aim as well as your specific goal.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
((lambda (x) `(,x ',x)) '(lambda (x) `(,x ',x)))
Erik Naggum
| If we "ignore package designators", the situation is trivial: if the
| argument to PACKAGE-NAME is not a PACKAGE, it is a TYPE-ERROR.
Good boy! You got the point exactly. It is not a `package-errorด.
| You missed your general aim as well as your specific goal.
Oh, Christ. Grow the hell up. You are not even able to focus on the
question you asked.
Somebody else can babysit you. What a fucking waste to answer you.
Paul F. Dietz
> So, what if we do _not_ ignore package designators?
> The two paragraphs that I quoted and you elided from my reply appear to
> imply that your answer to my question is PACKAGE-ERROR, not TYPE-ERROR.
>
> Let me repeat my question with "precision and clarity":
>
> What should the error type of
> (package-name "string which does not name any existing package")
> be?
As an aside, note that the standard uses different language for
some other package functions.
For PACKAGE-NAME:
"Should signal an error of type type-error if package is not a package designator."
For PACKAGE-USED-BY-LIST:
"Should signal an error of type type-error if package is not a package."
(in both cases, the package argument is supposed to be a package designator.)
Is this difference just accidental and irrelevant, or does it specify some
difference in behavior?
Paul
Kent M Pitman
> On Fri, 01 Nov 2002 22:14:38 GMT, Sam Steingold <s...@gnu.org> wrote:
>
> >what error should
> >
> >(progn (ignore-errors (delete-package "not a name"))
> > (package-name "not a name"))
> >
> >signal? CMUCL signals type-error, ACL and CLISP signal package-error.
> >
> >CLHS says that it should be type-error when the argument is not a
> >package designator, and the glossary entry for the latter ("object that
> >denotes a package" as opposed to "object that _CAN_ denote a package")
> >appears to imply that "CL" _IS_ a package designator because "CL" is a
> >nickname for the "COMMON-LISP" package, while "not a name" may or may
> >not be a package designator depending on the state of the system (i.e.,
> >whether "not a name" has been made the name or a nickname of a valid
> >package).
> >
> >What do people think?
> >
>
>
> ACL signals a package error regardless
>
> (package-name 5) --> package error
>
> which seems to be incorrect according to the HS.
Depends. The spec was written on the assumption of no multiple inheritance.
But the "right" solution (not required, but intended) is that if something
is both a type error and a package error, you mix both in.
The question of whether a "type" should be something that depends on program
state is of course the real philosophical question. Certainly CL permits it,
but it's problematic in certain ways.
The same issue used to come up in CLTL1 when we had defined functionp to
mean (or (real-function-p x) (symbolp x) (and (consp x) (eq (car x) 'lambda)))
because the SYMBOLP test is of course something that could be repaired.
Part of the issue is that the lack of definition might be accidental and
you might want to navigate into the part of the flow graph that deals
with symbolness (for this example) or packageness (for the example that
started this) so that when the thing is found to be undefined, fixing it
by defining it will leave you in the right place.
> I would say that if no package object can be obtained
> from the argument via permissable means the most
> reasonable interpretation of the HS is that a type error
> should be signalled.
Certainly this is a valid read and my comments are just one other person's
opinion. But the "right thing" will not be maintained by this in at least
some cases. Consider an argument that could be either a filename or package
name. If you assume that its non-packageness means it's a filename, then
when you get to the debugger and realize it's a package, you'll be in the
wrong part of the flow. I'm not saying there's a single unique right way
out--I'm just pointing out that finding a right course of action (vs. a
conforming course of action, which is easier) involves, in my opinion,
analyzing the likely places where this really happens and the most likely
to be preferred way of recovering when the situation is finally detected
and signaled.
> However, it would have been more appropriate to say that
> a package error should be signalled if the argument is
> a string designator and no package by that name can be
> found, while a type error should be signalled if the
> argument is neither a string designator nor a package object.
Yeah, a lot of this stuff was added by me in a 'discretionary' fashion
that was rubber-stamped by the committee at one point. We didn't have
the resources to do a super-good job at detailing all of this but wanted
to give at least some crude guidance. We tried to say the things that
were obvious and duck the hard cases, but even then there were simple
situations that are not simple--especially if you understand that at
the time, multiple inheritance was still regarded as questionable.