Clarifications please

[James J. Hunt <jjh@ll-vlsi.arpa>]

      2. Why isn't BOUND? known to Orbit (especially since *BOUND? exists)?

  It shouldn't be known to anyone.  Side effects to environments are
  meta-operations; the existence of things like BOUND? in the language (as
  opposed to the meta-language) breaks desirable invariants like
  order-independence of effectless definitions.

O.K. but from a more practical view what about BIND.  Suppose that I have
some variable *GLOBAL* that I need to dynamically bind for some group of
procedures: p1, p2, ... pn.  Furthermore I know that none of these will be
called before I execute some function that binds *GLOBAL*'s value.  BIND
insists that *GLOBAL* has a value BEFORE BIND of *GLOBAL* is used.  However
some other module may care about *GLOBAL*'s default value, so I would rather
not write something like (lset *GLOBAL* nil), but instead (if (bound?
*GLOBAL*) (then (lset *GLOBAL* nil))).  Of course, I would rather that BIND
did not depend on *GLOBAL* being bound.  There is also the case of porting
form other LISPs, however I have not YET seen a case where the such code
uses BOUNDP and does not also implicity expect that no one else is using the
variable in question.  In such places it is OK to initialize said variable
too either '() or '#f.  This does not mean that there aren't any.

       5.  Why not include this [Ellisp's IF] in T?

  T has COND.

This seems to be a rather weak answer.  If that is the reason why does T
have if at all.  It seems to me that IF is more readable than cons for
single test branching.  Likewise,

(if (test)
    (then (f1)
          ...
          (fn))
    (else (g1)
          ...
          (gn)))

seems to me much more readable then

(cond ((test)
       (f1)
       ...
       (fn))
      (else
       (g1)
       ...
       (gn))).

My point is that if T is going to support IF, why not support THEN and ELSE.
I even think (if (test) (then a) (else b)) is often more readable than the
more cryptic (if (test) a b).  (Though, the macro given defaults the else
clause to nil, I am not arguing that T should support that as well.  In
fact, it is only there because I gave into the local concensus --- at least
temporarily.)

      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).

I have two objections to this:

	1. It seem rather ugly to have to use two tables to keep track of
	   TABLE-HAS-ENTRY? state and the table values, as is need if you
	   don't plan to modify the source, and

	2. (walk-table (lambda (key value)
	                 (ignore value)
	                 (set (table-entry <table> key) '#f))
	     <table>)
	   does not work.  You must say (clean-table <table>).  Where as
	   this walk does work so long as you are not setting the table
	   value to '#f.  This seems to be a gross anomaly!  This is
	   especially painfull if the new value is computed from the old
	   one.

Thank you for taking the time to respond to my questions.

			-JJHunt