Naive T Design Questions Addendum

[gyro@kestrel.ARPA (Scott W. Layson)]

   Date: Tue, 26 Apr 88 16:18:41 EDT
   From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>

       Date: Thu, 14 Apr 88 21:59:49 EDT
       From: James J. Hunt <jjh at ll-vlsi.arpa>

       7. Why not separate the concept of () and no entry in tables?

   (I think you mean #F, not (), since absence of entry is indicated by a
   false return from table-entry.)  This is easily simulated given the
   existing primitives, so it would be an unnecessary complication.  E.g.
   it would require the addition of something like a TABLE-HAS-ENTRY?
   predicate, and it would require the addition of a separate procedure for
   deleting entries (currently you can just store a #F).

This reminds me, I really liked (at first sight, anyway) the idea of
providing a separate failure continuation for things like this (of
which I gather there are many).  The caller of something like
TABLE-ENTRY is almost certainly going to branch based on the returned
value anyway, so it seems like the failure-continuation approach
would be more efficient.  Has this been thought about much?

Besides, the failure-continuation approach would be more suitable for
a (gasp! heresy) strongly-typed language.  I know T will never become
one of THOSE, but I'm still curious what the impact would be like...

-- Scott