(define foo)

["Guillermo J. Rozas" <gjr@martigny.ai.mit.edu>]

   Date: Fri, 13 Nov 92 15:54:06 EST
   From: Marc Feeley <feeley@IRO.UMontreal.CA>
   Full-Name: Marc Feeley

   > As I remember, at one point we had achieved consensus on allowing
   > definitions of the form
   > 	(define foo)
   > to mean that foo is to become bound, but not assigned any particular
   > value; references to foo are errors until foo is assigned.
   > 
   > Are there any objections to this?  If not, I would encourage the
   > editor to put it in the next report.

   This is fine with me.  However, I think that references to foo prior to
   the first assignment should not be an error.  I prefer to think of this
   form as binding foo to an undefined value.  Thus:

     (define foo)     is equivalent to (define foo (if #f 'dummy))
     (eq? foo foo)    should not be an error and should return #t

I think the report should say that it is an error (not that it is
signalled), which means that portable programs cannot depend on any
particular behavior, but individual implementations can extend the
meaning.

MIT Scheme signals the error for top-level-bound variables but not
necessarily for variables DEFINEd internally.

   Question to all... should the same hold for bindings (in let, let*, ...)?
   For example:

     (let ((x) (y 5)) ...)

   For consistency it should be possible but I don't like it much...

If it is allowed in internal DEFINEs, then it must be allowed in
LETREC, since the report specifies that bodies with internal DEFINEs
can always be rewritten as such.

Once we allow it in LETREC, it does not make much sense to preclude it
in LET, LET*, or DO.

BTW, I use that all the time in MIT Scheme.