[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 18:09:30 MDT
- Apparently-to: email@example.com
- Newsgroups: fa.common-lisp
- Organization: University of Utah CS Dept
- References: <FAHLMAN.12218745136.BABYL@C.CS.CMU.EDU>
- Reply-to: shebs@utah-orion.UUCP (Stanley Shebs)
In article <FAHLMAN.12218745136.BABYL@C.CS.CMU.EDU> Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes:
>Or am I misunderstanding the goals of PCLS?
We're not going to live with it forever, it's just a hack so we can
learn CL implementation and figure out the right way to do a full CL.
We've waffled about error checking and cringed at the storage overhead of #2,
even though it's probably the best choice.
>The thought was that the user might want to convey more information
>about his preferences than would be possible in using binary-valued
>switches. A limited range of numbers seemed like the most reasonable
>and least confusing solution, though it's clearly not ideal. A number
>of the more complex CLisp implementations make good use of the
>multiplicity of values to fine-tune which optimizations their compiler
It's *probably* not a portability problem that (safety 1) means something
different in different implementations. PCLS uses the speed settings to
switch various kinds of optimizations, but we didn't have much intuition
about what the difference between (speed 2) and (speed 3) should be, and
it seemed that users who were picky about those things were just as likely
to want to know about PCLS's compiler flags that controlled each sort of
optimization. No big deal, I guess.