Re: dispatching on keywords

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

From: patl@goldfish.mitron.tek.com (Patrick Logan)
/// Subject: dispatching on keywords
/// 
///    Date: Fri, 13 Nov 1992 13:17:50 -0500
///    Agreed.  Yet another role for #none (or #nothing).  For that matter,
///    this gives the programmer a way of explicitly saying "I know that
///    there is a keyword K, but I do not want to provide a value for it",
///    not to be confused with "...and I give it the value #f":
/// 
/// Doesn't this lead to meta-circular madness? I mean, once there is an
/// object that is #nothing, then that object is something and will be
/// used for something, e.g., er, nothing.

This can be a problem, but I think it can be minimized by leaving "nothing"
values outside the class heterarchy, or at least ensure that <nothing> doesn't
inherit from <object>.

As heretical as that seems, I think it would discourage improper use of
"nothing" values.

/// The only way to ultimately step out of the problem is to have two
/// separate values: the data and the meta-data. The data is the value
/// desired and the meta-data is the separate indicator that indicates the
/// data is good, bad, missing, etc. It is trouble when one variable's
/// value is being used for both purposes.

If we provided _two_ types of "nothing" values, this wouldn't be such a
problem.  One can be used to signal an error and can have slots attached to it
for an error message, irritants, an os error code/etc.  Ergo:

	(open-file "my file")
	==> {some stream that I can't print}

	(open-file "this file should not be open-able (not found)")
	==> {error: file not found ... }

The other can be used for absent arguments, etc.  This gives us one value (a
'top' value) for cases where there is no value because of over-specification,
and another (a 'bottom' value) for cases where there is no value because of
under-specification (as in an uninitialized variable/slot/etc.)

Both of these values (or just the 'bottom' #nothing, if that's all that will be
provided) must exist OUTSIDE the class system to prevent them from being
abused.  Or perhaps create their own little class heterarchy, but don't let
them be considered as inheriting <object> behavior... Or we'll keep doint this
forever.

Nil didn't work for LISP as a bottom value, #f doesn't work for scheme, and
I think Dylan needs to fix this if it's going to bring dynamic programming back
in style.  "If I'm already paying the overhead of type-tags, let me use them
for significant other uses, like error flags...."

	-- Scot

P.S.  Just to try to make this germain to the discussion: not allowing
    specialization on key'ed arguments places severe limits on code
    reusability and maintainability to programmers who use keyword arguments
    _at_all_, since if they _ever_ need to be specialized, _all_ of the
    interfacing code must be changed (ick.)  This is the kind of problem I'd
    like an O-O environment to solve, not to create.