Hello,
should the following work or do I have to wrap the function definition in
an (EVAL-WHEN (:LOAD-TOPLEVEL)...)?
test.lisp:
(in-package :cl-user)
(defun test ()
"Doc"
nil)
(assert (documentation 'test 'function))
In REPL:
(load (compile-file "test"))
It works in CMUCL/SBCL, but not in ACL.
Thanks,
Nicolas.
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> should the following work or do I have to wrap the function definition in
> an (EVAL-WHEN (:LOAD-TOPLEVEL)...)?
> [...]
> (assert (documentation 'test 'function))
I believe that no implementation is ever required not to signal an
error on this form, as they are free to discard documentation strings
at any time for any reason. Is there a test case you can provide
without the DOCUMENTATION function?
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
>
>> should the following work or do I have to wrap the function definition in
>> an (EVAL-WHEN (:LOAD-TOPLEVEL)...)?
>
>> [...]
>> (assert (documentation 'test 'function))
>
> I believe that no implementation is ever required not to signal an
> error on this form, as they are free to discard documentation strings
> at any time for any reason. Is there a test case you can provide
> without the DOCUMENTATION function?
No, because my idea was to use the documentation string for generating also
an interactive demo:-)
Hmm, maybe the idea is not really that good. At least, I should accept it
to be NIL.
Nicolas.
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> Hello,
>
> should the following work or do I have to wrap the function definition in
> an (EVAL-WHEN (:LOAD-TOPLEVEL)...)?
>
> test.lisp:
>
> (in-package :cl-user)
>
> (defun test ()
> "Doc"
> nil)
>
> (assert (documentation 'test 'function))
>
>
> In REPL:
> (load (compile-file "test"))
>
> It works in CMUCL/SBCL, but not in ACL.
CLHS says clearly that:
defun is not required to perform any compile-time side effects. In
particular, defun does not make the function definition available at
compile time. An implementation may choose to store information about
the function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
Pascal Bourguignon <···@informatimago.com> writes:
> CLHS says clearly that:
>
> defun is not required to perform any compile-time side effects. In
> particular, defun does not make the function definition available at
> compile time. An implementation may choose to store information about
> the function for the purposes of compile-time error-checking (such as
> checking the number of arguments on calls), or to enable the function
> to be expanded inline.
As much as I see the problem lies not at compile-time (COMPILE-FILE works),
but at load-time.
Nicolas.
Nicolas Neuss <·······@iwr.uni-heidelberg.de> wrote:
+---------------
| Pascal Bourguignon <···@informatimago.com> writes:
| > CLHS says clearly that:
| > defun is not required to perform any compile-time side effects. In
| > particular, defun does not make the function definition available at
| > compile time. An implementation may choose to store information about
| > the function for the purposes of compile-time error-checking (such as
| > checking the number of arguments on calls), or to enable the function
| > to be expanded inline.
|
| As much as I see the problem lies not at compile-time (COMPILE-FILE works),
| but at load-time.
+---------------
Uh... You *do* understand that if your example is COMPILE-FILE'd
that the ASSERT will not run until *load* time, yes?
[Hint: Try MACROEXPAND on your ASSERT form and look at what the
"top-level" compile-time behavior of the resulting expansion is...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Uh... You *do* understand that if your example is COMPILE-FILE'd
> that the ASSERT will not run until *load* time, yes?
I think that's precisely the point. Let's recap:
(defun test () "doc" nil)
(assert (documentation 'test 'function))
If you load this as source, you would expect the test function to be
created and associated with the "doc" documentation string, and then
the assert to pass (assuming for the moment that your implementation
doesn't throw docstrings away). If you compile this file, then you
would expect a fasl to be written out; if you load this fasl, I at
least would expect first the test function to be created (and
associated with the "doc" docstring), and then the assert top-level
code to be run. I understood Nicholas' problem to be that, in some
implementations, the assert fails -- that is, puts him into the
debugger -- at load time, which is counter to intuition.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> I understood Nicholas' problem to be that, in some implementations, the
> assert fails -- that is, puts him into the debugger -- at load time,
> which is counter to intuition.
Precisely. Maybe this should be seen as an Allegro bug report[1], even if
I should not rely on documentation strings for my purposes (and do not do
so anymore, so I am quite satisfied that this Allegro behaviour made my bug
obvious).
Nicolas.
Christophe Rhodes <·····@cam.ac.uk> writes:
> ····@rpw3.org (Rob Warnock) writes:
>
>> Uh... You *do* understand that if your example is COMPILE-FILE'd
>> that the ASSERT will not run until *load* time, yes?
>
> I think that's precisely the point. Let's recap:
>
> (defun test () "doc" nil)
> (assert (documentation 'test 'function))
>
> If you load this as source, you would expect the test function to be
> created and associated with the "doc" documentation string, and then
> the assert to pass (assuming for the moment that your implementation
> doesn't throw docstrings away). If you compile this file, then you
> would expect a fasl to be written out; if you load this fasl, I at
> least would expect first the test function to be created (and
> associated with the "doc" docstring), and then the assert top-level
> code to be run. I understood Nicholas' problem to be that, in some
> implementations, the assert fails -- that is, puts him into the
> debugger -- at load time, which is counter to intuition.
But also CLHS specifies that implementations can drop the documentation strings.
clhs documentation:
Conforming programs are permitted to use documentation strings when
they are present, but should not depend for their correct behavior
on the presence of those documentation strings. An implementation
is permitted to discard documentation strings at any time for
implementation-defined reasons.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
Pascal Bourguignon <···@informatimago.com> writes:
> But also CLHS specifies that implementations can drop the
> documentation strings.
Pascal, please learn to read. I explained this not only in my
original reply to Nicholas, five days ago, but also in the very
message that you followed up to.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> But also CLHS specifies that implementations can drop the
>> documentation strings.
>
> Pascal, please learn to read. I explained this not only in my
> original reply to Nicholas, five days ago, but also in the very
> message that you followed up to.
Yes, but your intuition is still that (documentation 'test 'function)
should return a non nil.
--
__Pascal Bourguignon__ http://www.informatimago.com/
From: Kent M Pitman
Subject: Re: ANSI question (load evaluation order)
Date:
Message-ID: <uy8au7wjd.fsf@nhplace.com>
Pascal Bourguignon <···@informatimago.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > Pascal Bourguignon <···@informatimago.com> writes:
> >
> >> But also CLHS specifies that implementations can drop the
> >> documentation strings.
> >
> > Pascal, please learn to read. I explained this not only in my
> > original reply to Nicholas, five days ago, but also in the very
> > message that you followed up to.
>
> Yes, but your intuition is still that (documentation 'test 'function)
> should return a non nil.
Whose intuition? And why does anyone think their intuition has trump
over the standard?
The design decision was made, if you're curious, so as not to impede
the creation of embedded systems where space was at an extreme premium
and documentation strings might want to be dropped to save space. If
the language required them, it would have made Lisp seriously
non-competitive against other languages that could produce small
images.
In the face of separate compilation, you couldn't just assume that
DOCUMENTATION was never called unless you did block compilation of the
entire system. And yet if you left the info out, it would appear to
randomly violate the semantics of CL, and leave users distrusting that
the implementation was properly conforming. So we compromised and
said that people who ask for doc strings effectively have to test
whether they really got them before using them. This reduces it to a
conversation between you and your vendor about whether they provide
what you need, and leaves the vendor in a position to be responsive
rather than in a forced position of just having to shrug and say
"Sorry, ANSI required it. I can't do anything without being
non-conforming."
Not that being non-conforming is the end of life as we know it, but
vendors have been TRYING to pull together and cooperate, and I think
we should allow these variations in need cheerfully rather than
insisting that everyone have the same address space, the same stack
size, the same I/O devices, etc. Standardizing those won't change
what space, stack, and I/O is available int the world, it will just
lock Lisp out of certain markets.
Kent M Pitman <······@nhplace.com> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> Christophe Rhodes <·····@cam.ac.uk> writes:
>>
>> > Pascal Bourguignon <···@informatimago.com> writes:
>> >
>> >> But also CLHS specifies that implementations can drop the
>> >> documentation strings.
>> >
>> > Pascal, please learn to read. I explained this not only in my
>> > original reply to Nicholas, five days ago, but also in the very
>> > message that you followed up to.
>>
>> Yes, but your intuition is still that (documentation 'test 'function)
>> should return a non nil.
>
> Whose intuition?
| Christophe Rhodes <·····@cam.ac.uk> writes:
|
| > ····@rpw3.org (Rob Warnock) writes:
| >
| >> Uh... You *do* understand that if your example is COMPILE-FILE'd
| >> that the ASSERT will not run until *load* time, yes?
| >
| > I think that's precisely the point. Let's recap:
| >
| > (defun test () "doc" nil)
| > (assert (documentation 'test 'function))
| >
| > If you load this as source, you would expect the test function to be
| > created and associated with the "doc" documentation string, and then
| > the assert to pass (assuming for the moment that your implementation
| > doesn't throw docstrings away). If you compile this file, then you
| > would expect a fasl to be written out; if you load this fasl, I at
| > least would expect first the test function to be created (and
| > associated with the "doc" docstring), and then the assert top-level
| > code to be run. I understood Nicholas' problem to be that, in some
| > implementations, the assert fails -- that is, puts him into the
| > debugger -- at load time, which is counter to intuition.
> And why does anyone think their intuition has trump
> over the standard?
I don't know.
> The design decision was made, if you're curious, so as not to impede
> the creation of embedded systems where space was at an extreme premium
> and documentation strings might want to be dropped to save space. If
> the language required them, it would have made Lisp seriously
> non-competitive against other languages that could produce small
> images.
> [...]
This is clear.
Now, perhaps a slightly better specification would have been (CLRFI
candidate!) to mandate the same behavior for all implementations,
adding for example a declaration for compilation:
(optimize (keep-documentation t))
or:
(optimize (keep-documentation nil))
and we could even accept that it's implementation dependent whether
the default optimization value is t or nil for keep-documentation.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
From: Kent M Pitman
Subject: Re: ANSI question (load evaluation order)
Date:
Message-ID: <ud5s6blxq.fsf@nhplace.com>
Pascal Bourguignon <···@informatimago.com> writes:
> Now, perhaps a slightly better specification would have been (CLRFI
> candidate!) to mandate the same behavior for all implementations,
> adding for example a declaration for compilation:
>
> (optimize (keep-documentation t))
> or:
> (optimize (keep-documentation nil))
>
> and we could even accept that it's implementation dependent whether
> the default optimization value is t or nil for keep-documentation.
Most declarations are ignorable. Only a few are not. Somehow the idea
of making this one of the required ones sits poorly with me.
To quote (at least approximately) Jesse Ventura, an independent politician
(and wrestler, if I recall) in the US: "Government should do
for people only what they are not capable of doing for themselves."
DOCUMENTATION is a debugging tool, it is not intended for programs.
If you had pushed hard on this during the design process, people probably
would have dropped doc strings entirely.
What you want is, instead,
(DEFVAR *RELIABLE-DOC* (MAKE-HASH-TABLE))
(DEFUN DOC (X) (GETHASH X *RELIABLE-DOC*))
This will work reliably for you and is, by Jesse's rule, not something
you can't do for yourself. IMO, it has no business in Government, by which
I mean standards.
What do I do with a module A that contains (PROCLAIM '(KEEP-DOCUMENTATION T))
and module B that contains (PROCLAIM '(KEEP-DOCUMANTATION NIL)). The
"big switch" declaration just doesn't work well. We used to use them all
the time in Maclisp, pre-Common Lisp, and they were a disaster. The Maclisp
language, in the latter days, became little more than a toolbox for
implementing prototypes of Maclisp's successors, at least if you actually
USED any of the functionality we were piping out. Because in most cases,
if you set each "big switch" one way, it broke a bunch of libraries, and if
you used it another way, it broke others. And with more than one switch,
you can imagine the problems of intersections of usability. It was a mess,
and mostly we advocated people not using them.
The temptation is to think that language design is like programming, and
that you just add variables here and there to control things, but only some
things are susceptible to that. Language design has to serve all users,
and it has to make typical programs typically fit together. Things like
you suggest require setting switches "just so" if you want things to fit
together.
Kent Pitman wrote:
> To quote (at least approximately) Jesse Ventura, an independent politician
> (and wrestler, if I recall) in the US: "Government should do
> for people only what they are not capable of doing for themselves."
...
> What you want is, instead,
>
> (DEFVAR *RELIABLE-DOC* (MAKE-HASH-TABLE))
>
> (DEFUN DOC (X) (GETHASH X *RELIABLE-DOC*))
>
> This will work reliably for you and is, by Jesse's rule, not something
> you can't do for yourself. IMO, it has no business in Government, by which
> I mean standards.
By this criterion, most of what is now in Common Lisp
has no place in a standard. I find it hard to believe
that this is really what you want, so probably I'm
missing something. What?
--
Gareth McCaughan
.sig under construc
From: Kent M Pitman
Subject: Re: ANSI question (load evaluation order)
Date:
Message-ID: <uk6mdr1j4.fsf@nhplace.com>
Gareth McCaughan <················@pobox.com> writes:
> Kent Pitman wrote:
>
> > To quote (at least approximately) Jesse Ventura, an independent politician
> > (and wrestler, if I recall) in the US: "Government should do
> > for people only what they are not capable of doing for themselves."
> ...
> > What you want is, instead,
> >
> > (DEFVAR *RELIABLE-DOC* (MAKE-HASH-TABLE))
> >
> > (DEFUN DOC (X) (GETHASH X *RELIABLE-DOC*))
> >
> > This will work reliably for you and is, by Jesse's rule, not
> > something you can't do for yourself. IMO, it has no business in
> > Government, by which I mean standards.
>
> By this criterion, most of what is now in Common Lisp
> has no place in a standard. I find it hard to believe
> that this is really what you want, so probably I'm
> missing something. What?
You're right, I was probably being unduly harsh about the whole language.
In the ISO committee, there were days that some people wanted to be this
harsh with ISLISP. I recall someone sorting through the 6 comparison
operators (<, <=, =, /=, >=, >) and wanting to pick only 2 or 3 and
let users define the others. This didn't sit well. It wasn't until they
started to do the same to the trig functions that people got alarmed,
though... Just because you can compute TAN from SIN and COS doesn't mean
you should. There are roundoff error issues that users are better not
getting involved in if they can help it.
But I do think that we tended to apply a pretty harsh line in ANSI CL when
it came to the "environment". CLTL had provided more "environment" stuff
than ANSI CL did, and some wanted to provide none.
Kent M Pitman <······@nhplace.com> writes:
> [a long message with the content that implementations do not have to
> provide docstrings]
If I understand your message correctly this is completely uncontroversial
and was so since Christophe's first answer (so why are Rob Warnock, Pascal
Bourguignon, and now even you wasting time on this point?). But obviously,
Allegro CL provides docstrings. That is, after loading a file containing
the line
(defun test () "Doc" nil)
I can access the docstring with (documentation 'test 'function) from the
REPL. It therefore seems unnatural to me that a file containing the two
lines
(defun test () "Doc" nil)
(assert (documentation 'test 'function))
fails to load. When is the docstring made available? Is it at some
mysterious and implementation-dependent DOCSTRING-INSERTION-TIME occuring
after executing all commands in the file? Even if the spec might allow to
make the docstring available at random times, an implementation is
well-advised not do so.
Nicolas.
From: Kent M Pitman
Subject: Re: ANSI question (load evaluation order)
Date:
Message-ID: <u1x8mchwr.fsf@nhplace.com>
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> When is the docstring made available? Is it at some
> mysterious and implementation-dependent DOCSTRING-INSERTION-TIME occuring
> after executing all commands in the file? Even if the spec might allow to
> make the docstring available at random times, an implementation is
> well-advised not do so.
No. Implementations are king on this. The spec means to leave total
discretion to them. Let me, as others have already, repeat myself.
------> It's implementation-defined.
------> It's debugging data.
------> Don't rely on it in programs.
The fact that it's only vaguely specified is intended to give
implementors complete latitude and to make users have to ask the
implementor for details.
It's one of those things like the ED function or TRACE that is offered
to you as a low-tech way of making sure you can find the interface to
debugging data if such data is there at all. It doesn't promise to do
much that you can depend on programmatically. (Nor does TRACE or ED,
for example.)
We backed out of some "environment" issues in CLTL when we did ANSI
CL. We got rid of EVALHOOK, for example. A number of people thought
we should have backed out of more exactly because they are not
intended for programming. They really are intended to be "commands"
you invoke interactively if at all in the environment.
Yes, it's trivially true that you can call these things from programs,
so you can write programs with them. But you really aren't intended
to write production programs with them because, by design, they don't
offer you with functionality you can really usefully depend on. You
seem to somehow think this is a bug. It really is not.
I don't know how to make that more clear.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
> > [a long message with the content that implementations do not have to
> > provide docstrings]
>
> If I understand your message correctly this is completely uncontroversial
> and was so since Christophe's first answer (so why are Rob Warnock, Pascal
> Bourguignon, and now even you wasting time on this point?). But obviously,
> Allegro CL provides docstrings. That is, after loading a file containing
> the line
>
> (defun test () "Doc" nil)
>
> I can access the docstring with (documentation 'test 'function) from the
> REPL. It therefore seems unnatural to me that a file containing the two
> lines
>
> (defun test () "Doc" nil)
> (assert (documentation 'test 'function))
>
> fails to load. When is the docstring made available? Is it at some
> mysterious and implementation-dependent DOCSTRING-INSERTION-TIME occuring
> after executing all commands in the file? Even if the spec might allow to
> make the docstring available at random times, an implementation is
> well-advised not do so.
Nicolas,
I had a discussion internally with my colleagues, because like you,
I found the behavior to be non-intuitive. And I'll start by saying
that whether we find the behavior to be conforming or not, there is
one part of the spec which we fail to conform to, which is the
paragraph that others have brought up:
The sentence in question is "An implementation is permitted to
discard documentation strings at any time for implementation-defined
reasons." And there is a dictionary definition for
implementation-defined, which requires such implementation-dependent
behavior to be documented. We don't fully document this, and thus
we don't conform at least in that way. I will provide a little
of that missing documentation below, but I want to touch on a point
that I don't think has been addressed here yet:
This thread has centered around whether an implementation conforms
to the spec. However, no mention has been made to whether this code:
(defun test () "Doc" nil)
(assert (documentation 'test 'function))
is itself conformant code. And the answer is "No", it is not
conformant. Because the spec allows an implementation to throw
away doc strings at any time, consider the implementation which
takes full advantage of this and throws it away immediately after
the defun. Thus, your assert will fail. Thus your code is
not a "conforming program" as defined in the glossry.
And now, for an explanation of what is going on: You obviously see
the doc strings eventually, but it doesn't occur in the same
order as the defuns. The reason is that for reasons that Kent has
been explaining, we view doc strings to be not part of the functionality
of the program, and thus discardable (as the spec says). But more
subtlely, we view doc strings as optional information, similar to
debug information, which we place at the end of the fasl file so that
it is easier to make decisions about whether to even load it or not (see
http://www.franz.com/support/documentation/7.0/doc/variables/excl/s_load-documentation_s.htm
for documentation [sic :-] on leaving out documentation strings).
In general, Common Lisp object file formats (i.e. fasl files) tend
to be sequential in nature due to the requirements of the language.
However, there is something to be said for the sectionalizing that
is typically done by other standard object-file formats (e.g. COFF,
ELF, etc); these allow better modularization and easier access to
information that is optional and may even be able to be stripped
away before shipping in a runtime or a JIT-like environment. We
happen to be agressive in that respect when it comes to doc strings.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Kent M Pitman
Subject: Re: ANSI question (load evaluation order)
Date:
Message-ID: <uoebpr1qo.fsf@nhplace.com>
Duane Rettig <·····@franz.com> writes:
> This thread has centered around whether an implementation conforms
> to the spec. However, no mention has been made to whether this code:
>
> (defun test () "Doc" nil)
> (assert (documentation 'test 'function))
>
> is itself conformant code. And the answer is "No", it is not
> conformant. Because the spec allows an implementation to throw
> away doc strings at any time, consider the implementation which
> takes full advantage of this and throws it away immediately after
> the defun. Thus, your assert will fail. Thus your code is
> not a "conforming program" as defined in the glossry.
Are you sure? I thought an explicit call to ERROR was conforming.
How is this different?
Conforming doesn't mean code won't signal errors. It means code won't
behave as described.
I think this code will behave as described. That is, it will enter
the debugger if a certain situation occurs, a situation that happens to
be implementation-defined.
It's a long-standing question, and I don't know that it's well
answered by the spec ... I think it's left a bit fuzzy ... whether
it's possible to write a non-portable program that is conforming. I
think it probably is. That is, conformance is not a guarantee that
your program will do what you expect in all implementations. Either
that, or conformance is a subjective measure, since in that case it
can't mean anything without a persons expectations against which to be
measured.
I dont think it hurts anything for there to be wiggle room on this detail.
But it's worth alerting people to the fact that there is.
Kent M Pitman <······@nhplace.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > This thread has centered around whether an implementation conforms
> > to the spec. However, no mention has been made to whether this code:
> >
> > (defun test () "Doc" nil)
> > (assert (documentation 'test 'function))
> >
> > is itself conformant code. And the answer is "No", it is not
> > conformant. Because the spec allows an implementation to throw
> > away doc strings at any time, consider the implementation which
> > takes full advantage of this and throws it away immediately after
> > the defun. Thus, your assert will fail. Thus your code is
> > not a "conforming program" as defined in the glossry.
>
> Are you sure? I thought an explicit call to ERROR was conforming.
> How is this different?
>
> Conforming doesn't mean code won't signal errors. It means code won't
> behave as described.
>
> I think this code will behave as described. That is, it will enter
> the debugger if a certain situation occurs, a situation that happens to
> be implementation-defined.
I am confused as to what is being discussed here. What I am discussing
myself is what would seem to be the intuition that the documentation
method will not return nil, and that thus that the assert will not
call error. The behavior of assert is not in question, only whether
documentation can return nil or not, and since acording to the spec
it can, it is thus not portable to assume that assert will not call
error.
> It's a long-standing question, and I don't know that it's well
> answered by the spec ... I think it's left a bit fuzzy ... whether
> it's possible to write a non-portable program that is conforming. I
> think it probably is. That is, conformance is not a guarantee that
> your program will do what you expect in all implementations. Either
> that, or conformance is a subjective measure, since in that case it
> can't mean anything without a persons expectations against which to be
> measured.
I disagree, based on the way I read the glossary definition of "conforming
program", especially the phrase "and can therefore be expected to run
correctly in any conforming implementation." Since the program has
used an assert, it is an indication of the programmer's intent - i.e.
that the documentation form should return a non-nil value and that an
assertion failure is thus signalling a situation that is considered
incorrect by the program.
Do you interpret this definition differently? Or the intent of the
assert differently? Or am I missing something else?
> I dont think it hurts anything for there to be wiggle room on this detail.
> But it's worth alerting people to the fact that there is.
I guess I just don't see that wiggle room, since the spec seems
fairly explicit about it.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Kent M Pitman
Subject: Re: ANSI question (load evaluation order)
Date:
Message-ID: <u64xxqpgv.fsf@nhplace.com>
Duane Rettig <·····@franz.com> writes:
> > It's a long-standing question, and I don't know that it's well
> > answered by the spec ... I think it's left a bit fuzzy ... whether
> > it's possible to write a non-portable program that is conforming. I
> > think it probably is. That is, conformance is not a guarantee that
> > your program will do what you expect in all implementations. Either
> > that, or conformance is a subjective measure, since in that case it
> > can't mean anything without a persons expectations against which to be
> > measured.
>
> I disagree, based on the way I read the glossary definition of "conforming
> program", especially the phrase "and can therefore be expected to run
> correctly in any conforming implementation." Since the program has
> used an assert, it is an indication of the programmer's intent - i.e.
> that the documentation form should return a non-nil value and that an
> assertion failure is thus signalling a situation that is considered
> incorrect by the program.
If I didn't say it clearly enough, I think this is slightly
subjective. A possible reading of ASSERT is "Tell me if I violated a
constraint or made a wrong supposition." I'm not saying our reading
isn't valid, just that there may be others. For example, I might
insert an ASSERT if I think an algorithm shouldn't fail but I want to
double-check. In that case, the ASSERT's primary purpose is to catch
program errors. Or I might put the ASSERT in a program where I've not
ported it to all possible systems. In that case, there is no program
error to catch; it's trying to catch a case where the user tries to
run the program before it's properly ported to a new environment. And
in that case, the program is correctly saying "I don't run here." it
is not simply passively failing to run, nor is it reporting that the
person who wrote the code has made an erroneous assumption--s/he's made
a correct assumption by correctly predicting that it is possible or
someone to abuse what may be a published condition about where this
code is valid to call. The differences between these two possible
meanings is subjective, but I think important, and leads to different
ways of viewing the situation.
It seems to me, at least in one of the above situations if not both,
it's ASSERT's willingness to reliably stop a program dead in its
tracks when a programmatically described condition occurs that allows
it to have any semantics at all. If it were non-conforming, I
couldn't count on it to signal an error and I might as well not use
it.
I agree that the program might not be running properly when the ASSERT
fails, but it seems to me that it's some other part of the program
(the caller), not this part of the program (the ASSERT, which is keeping
me from running away when something else was already done wrong) that
is in error.
And as to whether the fact that the rest of the program did this proves
the program is non-conforming, that's hard to say. I'd say there are
other ways than non-conformingness that one can make a program error.
If you are really ambitious about this, the first page or two of my
1990 paper on Exceptional Situations will talk about where I'm coming
from in this. It talks about the subjective line between normal
and exceptional cases and gives some examples.
> > I dont think it hurts anything for there to be wiggle room on this detail.
> > But it's worth alerting people to the fact that there is.
>
> I guess I just don't see that wiggle room, since the spec seems
> fairly explicit about it.
I'm not trying to assert a superior point of view to yours, btw. I'm
long done with the editing and my reading is just as plausible as
yours. I've long known about this issue and can see it from both
sides. It seems a philosophical tangle to me. I've not ever tried to
sit down and untangle the terminology into what I'd accept as
unambiguous terminology. I imagine that must be possible. The
wording in the spec is just "the best I could do at the time".
Kent M Pitman <······@nhplace.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > > It's a long-standing question, and I don't know that it's well
> > > answered by the spec ... I think it's left a bit fuzzy ... whether
> > > it's possible to write a non-portable program that is conforming. I
> > > think it probably is. That is, conformance is not a guarantee that
> > > your program will do what you expect in all implementations. Either
> > > that, or conformance is a subjective measure, since in that case it
> > > can't mean anything without a persons expectations against which to be
> > > measured.
> >
> > I disagree, based on the way I read the glossary definition of "conforming
> > program", especially the phrase "and can therefore be expected to run
> > correctly in any conforming implementation." Since the program has
> > used an assert, it is an indication of the programmer's intent - i.e.
> > that the documentation form should return a non-nil value and that an
> > assertion failure is thus signalling a situation that is considered
> > incorrect by the program.
>
> If I didn't say it clearly enough, I think this is slightly
> subjective. A possible reading of ASSERT is "Tell me if I violated a
> constraint or made a wrong supposition."
Yes, I agree. The suppostion here is that the programmer has made
a supposition. And the nice thing about ASSERT is that it does a
good job of codifying the assumptions that have been made. In the
case we were discussing, it is fairly obvious that the OP was intending
that the defun install a documentation string in a manner that is
timely to the next top-level form in the file.
So the question becomes: Is the ASSERT form a part of the program?
I believe that it is; it is a codification of the programmers
assumptions about other parts of the program. So then, the next
question becomes: is the assumption that the doc string is installed
as part of the defun a part of the program? And I believe that the
answer is no, _unless_ the programmer codifies his assumption, with
an ASSERT form or perhaps with any other form which uses the assumption;
for example, it may be that he had originally not had an assert, but
instead had some other form such as (defparameter *test-doc*
(documentation 'test 'function), but since that would result in a
value of *test-doc* that sometimes ended up being nil, he may have
then simplified the failure of his assumptions for the purposes of
posting it here.
I'm not saying our reading
> isn't valid, just that there may be others. For example, I might
> insert an ASSERT if I think an algorithm shouldn't fail but I want to
> double-check. In that case, the ASSERT's primary purpose is to catch
> program errors. Or I might put the ASSERT in a program where I've not
> ported it to all possible systems. In that case, there is no program
> error to catch; it's trying to catch a case where the user tries to
> run the program before it's properly ported to a new environment. And
> in that case, the program is correctly saying "I don't run here." it
> is not simply passively failing to run, nor is it reporting that the
> person who wrote the code has made an erroneous assumption--s/he's made
> a correct assumption by correctly predicting that it is possible or
> someone to abuse what may be a published condition about where this
> code is valid to call. The differences between these two possible
> meanings is subjective, but I think important, and leads to different
> ways of viewing the situation.
Agreed.
> It seems to me, at least in one of the above situations if not both,
> it's ASSERT's willingness to reliably stop a program dead in its
> tracks when a programmatically described condition occurs that allows
> it to have any semantics at all. If it were non-conforming, I
> couldn't count on it to signal an error and I might as well not use
> it.
Right. ASSERT allows assumptions to be stated immediately, rather than
relying on program state to show the assumptions indirectly. Back to
my previous example, a defparameter form would have yielded a symbol whose
value is nil, but there is not a direct correlation between that state
and what is in the programmers mind (e.g. "I want to save the documentation
for the defun I just did into a global variable"). The fact that ASSERT
pointed out the invalid assumption more directly that a DEFPARAMETER form
would have done doesn't incriminate ASSERT as being non-conforming, nor
even its use; instead it incriminates the assumption that had been underlying
in its use - an assumption that the spec.
> I agree that the program might not be running properly when the ASSERT
> fails, but it seems to me that it's some other part of the program
> (the caller), not this part of the program (the ASSERT, which is keeping
> me from running away when something else was already done wrong) that
> is in error.
Right; it is not the ASSERT itself, but what the assert codifies, which
is the assumption of when information will be available (which the spec
says should not be codified to assume).
> And as to whether the fact that the rest of the program did this proves
> the program is non-conforming, that's hard to say. I'd say there are
> other ways than non-conformingness that one can make a program error.
>
> If you are really ambitious about this, the first page or two of my
> 1990 paper on Exceptional Situations will talk about where I'm coming
> from in this. It talks about the subjective line between normal
> and exceptional cases and gives some examples.
Yes, I glanced at it; I came away with the feeling that you viewed
the exceptional situations to be not part of the program. Of course,
it is true that exceptional situations are not part of the normal
program _flow_, but are you aware of how many of use have actually
resorted to using exceptional situations in a _normal_ prrogram
flow setting? I think that the reasons for this have to do with the
extreme ease of use of handler-bind et al, coupled with the emergence
and wide acceptance/use of try/except forms in C++ and Java. So
perhaps your programming idea for exceptions has turned into a
monster :-)
> > > I dont think it hurts anything for there to be wiggle room on this detail.
> > > But it's worth alerting people to the fact that there is.
> >
> > I guess I just don't see that wiggle room, since the spec seems
> > fairly explicit about it.
>
> I'm not trying to assert a superior point of view to yours, btw. I'm
> long done with the editing and my reading is just as plausible as
> yours. I've long known about this issue and can see it from both
> sides. It seems a philosophical tangle to me. I've not ever tried to
> sit down and untangle the terminology into what I'd accept as
> unambiguous terminology. I imagine that must be possible. The
> wording in the spec is just "the best I could do at the time".
Heh, you might desire to discount the words you used in the final
document, but be aware that those words are indeed hung on, if only
for the very reason of being canonized as the spec. The amazing thing
about the spec is how much of it is in fact very consistent within
itself, and how complete it seems to be in spite of your apologies.
It's like a musician performing; he always hears every mistake,
but many times nobody else does.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> [perfect explanation]
Thank you, Duane, I am completely satisfied with this. As always you prove
that Franz cares for its implementation very much.
Nicolas.