Re: #f = #none ?

[alms@cambridge.apple.com (Andrew LM Shalit)]

At  2:43 PM 11/19/92 -0800, Scot Dyer wrote:
> 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.

Our original design of Dylan had an object called $unsupplied.  We ended
up abandoning it for exactly the reasons Bob is pointing out.  People got
tripped up by it too often.  They ended up passing it around in an effort
to default their protocols, but then (because they were treating it as
data) it ended up messing up other protocols.

I think that it's extremely unlikely that we would reconsider this decision
at this time.  There are other solutions to the problem, and there are
plenty of other problems in Dylan which don't yet have existing solutions.