gcl-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]