Re: #f = #none ?

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

At  9:00 AM 11/24/92 -0800, Scot Dyer wrote:
> From alms@cambridge.apple.com Mon Nov 23 17:18:46 1992
> 
> |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.
> 
> Any language construct can be abused.  While this consideration has effected
> many language designs, I have yet to see one that prohibits hard to read, hard
> to maintain code yet!  :-)  This is a valid consideration, though, although I
> might be faster to use it as a reason to leave out multiple-inheritance than
> functional condition handling.

The problem wasn't abuse.  The problem was that they had a hard time under-
standing how to properly use it (partly because we couldn't explain a proper
way to use it).

> |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.
> 
> I can understand this.  It is difficult to do cleanly, and would require
> revision of method-dispatch (IMHO) to do it right.  Some would say this was
> a 'hack.'
> 
> Since #none (or some equivalent bottom value) is not going to be provided in
> Dylan, I have a proposal which might satisfy a large number of those concerned
> about the use of #f.  Of course, I expect some people will have problems with
> parts of this, so I'll try to make it modular in the hopes that it can serve
> as a basis for resolving what concerns remain about the current handling of
> #f as a bottom value.
> 
>         1) Provide a <boolean> class, and let people explicitely cast to it
>            for the 'anything but #f is true' cases.
> 
>         2) Provide a special-form predicate for testing if a bottom condition
>            is being returned.  I say a special form since it needs to be given
>            a parameter that may not normally evaluate without causing an error.
>            Possible names (and semmantics for which cases return #t and #f)
>            include:     bound?/unbound?
>                         specified?/unspecified?  (I like these, personally)
>                         provided?
>                         initialized?/uninitialized?
> 
>         3) Use this special form in the places where #f is currently supplied
>            as a bottom value.  If desired, multiple special forms could be
>            given (along the vein of slot-initialized?), or all these could be
>            unified under a single name.  In all other cases, an attempt to
>            access these values should result in an exception.
> 
>            These places where #f is currently supplied include: bind, optional
>            parameters, and where else?
> 
> What do people think of this?  Is it a fair compromise?

I think this solution is bigger than the problem it solves.  But perhaps that's
just because I'm conservative.  To really judge I'd need to see a complete
proposal, I'd need to try programming in the resulting language, and I'd need
to try to explain the resulting language to a beginner.

Now for a meta comment:

In general, we are going to be very conservative in changes we make to Dylan
at this time.  We want to avoid complications or untested changes to the basic
language model.  We want to make it easier to compile the language and deliver
small, efficient applications.  We want to make the language more accessible to
static language programmers.  And we want to fix things which simply cannot work
as currently specified.

There are lots of directions that people could take Dylan.  I'd love to see
people explore some of these directions in their own implementations.  If an idea
prove itself, we'll probably use it in the future (or some other language
will).

So, keep exploring, but please understand if we don't follow at this time.

   -Andrew Shalit
    alms@cambridge.apple.com