Re: bounded, infinite ranges?

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

///    ...My reason: a range is over floats, yes?  Therefore no
///    enumerative approach would terminate (any range has an infinite
///    number of elements), even if one was provided.
/// 
/// Huh?  Floats are not reals -- after all, they're represented finitely.
/// 
/// As for the meaning of IEEE infinity, it is not really infinity either:
/// it stands for all numbers too large to represent in a given floating
/// type.

Programs I have written using this kind of knowledge are usually cryptic at
best.  Also, generating the elements of the range sequentially may be
non-trivial, and there are usually way too many to be useful.

///    These values that sit outside the system, "top" and "bottom" values
///    are usually very important to a program.  IMHO, it was unfortunate
///    that they were left out of the Dylan language spec.
/// 
/// I agree.  Dylan appears to use #f as a substitute for a void value in
/// some cases, e.g. while, until, bind with no forms.  This, and the fact
/// that ANY non-#f value is true, seem to be residual Lispisms.

Providing a structured "bottom" would present one aesthetically pleasing
solution to this.  Ergo (and 1 #f) --> {bottom: and of non-boolean: 1}.  This
also preserves the focus on values, rather than control mechanisms.

Treating bottom values as not inheritting <object> (since they aren't valid
objects, but rather 'outside the normal system') would make integration of
such values into an exception system a bit easier.  When no method can be
found to apply (no error correcting method), program execution could halt with
a back-trace (the bottom value having accumulated this on the way out...)
Either that or create {bottom: no applicable method}

Something like: {bottom: car {bottom: car ()}} would be the error from
(car (car '())).  Of course, pretty-printing such values would be important.

Arranging these bottom values into a class heterarchy (as Dylan already so
wisely does with exceptions, IMHO) gives programmers good flexibility insofar
as where to catch the error/exception.  Given that exceptions are exceptional,
too, the cost of backing out and collecting the trace seems minimal, especially
since that information should be accessible to the program...

/// Note that adding void to the possible returns of a function increases
/// function-return overhead, since of course you have to find some place
/// for the necessary bits....  (If you do it by some control convention,
/// there is still some overhead somewhere.)

Dylan already pays the full price of type tags.  I say take advantage of them.

///         -s

	-- Scot

P.S.  Perhaps we should be creating a new mailing-list, for Dylan specification
    requests and/or conversations.  I don't want to waste the signal-to-noise
    ratio in this group, but this stuff seems like an important consideration.
    Even though (unless we're all going to implement Dylan supersets -- another
    PL/I disaster! :-) they could be construed as pertaining to implementation.

      I hope someone at Apple hears this.  I should suspect that someone there
    will read all these messages...