[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: crummy lisps
From: |
jeff |
Subject: |
Re: [Gcl-devel] Re: crummy lisps |
Date: |
Tue, 9 Aug 2005 17:11:06 +0100 |
User-agent: |
Internet Messaging Program (IMP) 3.2.3 |
Quoting Camm Maguire <address@hidden>:
> Greetings! This is my understanding too, and general goal that the
> compiler should follow. Whether we achieve this is of course another
> matter entirely, especially as most everyone runs at safety 0 leaving
> safety 3 with little feedback.
>
> Take care,
>
> Robert Boyer <address@hidden> writes:
>
> > I should add the following.
> >
> > I think it is generally accepted rule of thumb in the Common Lisp
> > community that if you compile and execute with SAFETY = 3, then
> > your Lisp job will not die some horrible death (e.g., with a
> > segmentation violation) because someone did an RPLACA or a
> > SETF-AREF on some garbage, and thereby randomly zapped
> > memory. Another way of thinking about this is that at SAFETY = 3,
> > life is almost as nice as it always was on a Lisp machine.
> >
> > I do not think that the ANSI standard in any way requires this "rule of
> > thumb". Maybe it should. Maybe the authors thought it did. But I can't
> > find it in writing and would happy if you told me where to look.
I don't know of any one place in the spec that says it "globally".
Instead(?), there's a definition of "safe code" (below) which
has implications for the phrase "the function F should signal
an error", and then each function specification has to indicate
the cases that fall under the rule.
Safe code (from the Hyperspec):
This is code processed with the safety optimization at its
highest setting (3). safety is a lexical property of code.
The phrase ``the function F should signal an error'' means
that if F is invoked from code processed with the highest
safety optimization, an error is signaled. It is
implementation-dependent whether F or the calling code
signals the error.
There are some other relevant things in the same saection,
"Error Terminology": http://www.lisp.org/HyperSpec/Body/sec_1-4-2.html
Then, looking at rplaca, we find in "Exceptional Situations":
Should signal an error of type type-error if cons is not a cons.
For elt and setf of elt:
Should be prepared to signal an error of type type-error if
sequence is not a proper sequence. Should signal an error of
type type-error if index is not a valid sequence index for
sequence.
But for aref, it says
Exceptional Situations: None.
:(
It's odd that nothing is said, so I'm wondering whether there's
something somewhere else that somehow implies that some kind of
checking (is that enough "some"s?) is done in safe code.
-- Jeff