[no subject]

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.

|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 don't want Dylan to contain hygenic problems.  If the designers of Dylan have
found #none to be one, I think it should be abandoned (at least in 'Dylan'),
but in order to do so hygenically we need some way to avoid LISPs 'nil [or #f]
is either a bottom value or a real value.'  What do _you_ think of this, alms?

	-- Scot