[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Error Signalling
- Subject: Re: Error Signalling
- From: firstname.lastname@example.org (Stanley Shebs)
- Date: Sun, 29 Jun 86 12:49:29 MDT
- Apparently-to: email@example.com
- Newsgroups: fa.common-lisp
- Organization: University of Utah CS Dept
- References: <FAHLMAN.12218043005.BABYL@C.CS.CMU.EDU>
- Reply-to: shebs@utah-orion.UUCP (Stanley Shebs)
In article <FAHLMAN.12218043005.BABYL@C.CS.CMU.EDU> Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes:
>2. The rigorous solution: For errors of the types described above, it is
>REQUIRED that implementations signal an error in interpreted code. It
>is also required that these errors be signalled in compiled code unless
>(optimize (safety 0)) is in effect at compile time.
This would be good - I bet a lot of system code would benefit from the
scrutiny necessary to fix this up. Will increase size of implementations,
especially those that need to have two versions of function (safe one calls
unsafe one, of course, but still some overhead I think).
BTW, why not flush the silly numbers and use t,nil or else keyword names
like :unsafe and :bombproof and :nuclear-qualified? 0s and 3s don't
convey much meaning....