On Thu, Apr 04, 2002 at 06:42:57PM -0600, William Harold Newman wrote:
> On Wed, Apr 03, 2002 at 06:33:03PM +0100, Christophe Rhodes wrote:
> > Attached are two things: a patch that causes sbcl to get the atom type
> > right (I believe), and a rather stream-of-consciousness ramble about
> > what I did to implement it. There were some nasty surprises along the
> > way, and the patch could probably do with review anyway as there are
> > non-obvious portions to it, and at least two portions that could do with
> > changing (the :complex-subtypep-arg2 bit marked with a FIXME, and the
> > fact that I've forgotten to export *atom-type*).
> Review, hmm.
:-) I thought it might be slightly controversial; these things generally
are. I confess that I was more surprised at the fact that the typep
optimizer was necessary -- any thoughts on that?
> it bugs me I might even be motivated to try it another way.
There is one other way that I haven't actually explored that might work,
but it would be more complicated...
> I liked your first approach (the "obvious solution"), changing the
> invocation protocol so it tries the other way when it gets an
> uncertain value. But if it turns out to be too painful to get it to
> work with all the implicit assumptions in all the other type methods,
> that's a pretty good reason not to do it.:-(
There's a potential modification to the obvious solution that might
work, too, though it's again fairly complicated: instead of modifying
the protocol to try again if it's uncertain, modify the protocol to have
/three/ return values (boolean, certainty, do-we-want-to-try-again?), so
that we can distinguish between "return NIL, NIL because that's the best
we can ever do" and "dunno".
> Incidentally, I didn't understand your remark about this obvious
> solution and the "no CLOS" restriction.
> > This points towards an obvious solution (well, it's obvious if you
> > accept the "no CLOS" restriction that is currently imposed by our
> > build process): why not change the invocation protocol
> > ([!%]INVOKE-TYPE-METHOD) so that if one of the
> > FOO-COMPLEX-SUBTYPEP-ARGn-TYPE-METHODs expresses uncertainty, try the
> > other one?
> Do you mean there'd be a better way to do it under CLOS (e.g. putting
> in a special multimethod CSUBTYPEP (HAIRY-TYPE UNION-TYPE) and letting
> it take precedence), or that this approach would be be awkward under
> CLOS, or what?
Sorry -- I meant that with CLOS we can if necessary use eql-specified
methods and localize the information so that things are more obvious.
Here might be a good point to mention that the other possibility that I
haven't explored is to have a NEGATION-TYPE (analogous to UNION- and
INTERSECTION-TYPE), and move the logic around; I haven't thought about
it deeply (it was a holiday, after all :-) but that might get round the
problem, again my increasing the locality of the information -- I think
you'd still have to make the modification of the protocol that was the
"obvious solution", but I have kept my working...
> My concern about the approach you finally used is that it seems to
> require a fair amount of global knowledge of the type system to
> understand some of the local code, if only because it expands the
> existing annoying class of "things like *WILD-TYPE* and
> *UNIVERSAL-TYPE* that get treated specially". If I'm still worrying
> about it tomorrow maybe I'll even be motivated to experiment with the
> CLOS-style multimethod solution. I can think of two non-CLOS
> mechanisms to do that (either hacking INVOKE-TYPE-METHOD, or more
> likely just doing some sort of double dispatch) and it's possible that
> that wouldn't be too bad.
Sure. Well, if that works, that would be great (I certainly wouldn't
complain); I don't think there's a vast amount of special-casing of
*ATOM-TYPE*, though -- the only surprise was that it was necessary to
include the optimizer for it in TYPEP.
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)