Re: #f = #none ?

[dyer@eagle.sharebase.com (Scot Dyer)]

From: Bob Kerns <rwk@crl.dec.com>
/// 
///     Date: Thu, 19 Nov 1992 11:41:07 PST
///     From: Jim Mayer <mayer@wrc.xerox.com>
/// 
///     Why is that a problem?  Under the semantics I gave above, #none is a
///     perfectly good value.  If no default is given, it is passed right
///     through and the "right" thing would happen at the fuction that was
///     prepared to do the defaulting.

Aha!  This really seems like the core issue to resolve with #none -- whether
or not it should be considered part of <object>.  If it is not, then this
passing down won't work as expected.  Then again, proper initial design of
the inter-layer protocols would avoid this problem.

/// It suffers from the same punning problems as NIL.  Anytime
/// you try encoding this out-of-band information in-band in
/// the data object, you incur risk of punning.  Consider a
/// compiler or macro cogitating about what to do with this
/// #none argument.

I think the Dylan spec says that dynamic typing is possible (I sure hope it
does!), and it is as complex a matter for #none as for any other dynamically
typed situation as far as the compiler is concerned.  It _must_ emit code with
a conditional on the dope-vector/type-tag of what it is passed.  Optimizations
_do_ abound, and _should_ be made by a suitable Dylan compiler, so #none should
pose no new difficulties in that regard.  By the time the compiler has figured
out where it can emit statically typed code, it is not at all difficult to
handle #none correctly.

Aside:  IF WE ARE SERIOUSLY CONSIDERING #NONE, WE NEED TO TALK ABOUT WHAT
    CLASS IT WILL BE.  I SUGGEST MAKING IT _NOT_ INHERIT OBJECT BEHAVIOR SO
    THAT METHODS THAT DO NOT SPECIALIZE ON ARGUMENTS CAN BE GUARANTEED OF NOT
    RECEIVING #NONE FOR A REQUIRED ARGUMENT BY THE METHOD-DISPATCH PROCEDURE.

Sorry about the CAPs, but I haven't really heard from anyone on this topic,
and I don't see how this discussion can continue without it.  What class should
#none be?  Should it even _have_ a class?  (I think it should)

	-- Scot