[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: THE-AMBIGUITY
- To: masinter.pa@Xerox.COM
- Subject: Issue: THE-AMBIGUITY
- From: jar@void.ai.mit.edu (Jonathan Rees)
- Date: Fri, 21 Oct 88 18:27:19 EDT
- Cc: cl-cleanup@sail.stanford.edu
- In-reply-to: masinter.pa@Xerox.COM's message of 21 Oct 88 13:38 PDT <881021-133834-6458@Xerox>
- Reply-to: jar@zurich.ai.mit.edu
Date: 21 Oct 88 13:38 PDT
From: masinter.pa@Xerox.COM
On your proposed implementation: one string of issues that I still hope we
can resolve (if not by first draft) is to specify more fully the types of
errors signalled. CONDITIONS:INVALID-TYPE-SPECIFIER seems like a reasonable
error for TYPEP to signal if it is given one. An implementation of THE
might want to handler-bind that particular condition, although it would be
free to do something else instead.
This implementation doesn't quite work because then there'd be no way
to distinguish between
(the (integer you lose big) #'cons)
and
(the (function (t t) cons) #'cons),
the first of which should be an error and the second of which shouldn't.
I think there would have to be a distinct condition type, maybe
INAPPROPRIATE-TYPE-SPECIFIER, for valid type specifiers that are used
in the wrong context.
Also, in considering possible ways in which the type-checking logic
for THE and DECLARE might work, don't forget things like
(the (not (function (t t) integer)) 7),
which you would want to signal an error. I don't think this can be
done with only TYPEP and conditions.
Jonathan