[REBOL] Open Letter [was: Series Index Discussion]
From: joel::neely::fedex::com at: 27-Feb-2003 9:19
Hi, Carl,
I hardly know how to reply, but as I have actively participated
in the disussion, I assume I am one of "the same three people"
and feel obligated to try.
Carl Sassenrath wrote:
> WRT the series discussion that pops up every year on this list:
>
I searched using eScribe with the terms "series" and "index?".
We've certainly had various discussions about series values in
the past, but I didn't find a discussion of the issue at hand.
This discussion was stimulated by the fact that the Core 2.5.5
beta changes the behavior associated with "off the end" series
references.
I've always understood the release of beta product (whether to
the general public or to a specific group of users, such as this
list) as an invitation to discuss the changes/bugs discovered in
the release. (That's certainly what I've meant by beta releases
of software I've written.) As the Core 2.5.5 beta announcement
was made to this list, it seemed to be the right place to have
that conversation.
I can't speak for the other two (of "the same three" ;-) but
that's what I thought we were doing.
> 1. Typically, this discussion is between the same three people
> who discuss the merits of other indexing methods and theories.
>
The discussion wasn't about "other indexing methods". It was
about what might be a better (as in "more easily usable") way
to handle out-of-bounds series references than the change that
showed up in the Core 2.5.5 beta.
> 2. The current series index implementation is based on
> performance, not strict theory...
>
The discussion hasn't been about performance (nor theory) but
about the possible problems of having a series reference that
seems to change its INDEX? value as a side-effect of changes to
a different reference to the same series. AFAICT, none of the
ideas pitched in for discussion would have significant effects
on performance.
> 5. It has been proposed...
> Please use REBOL naming conventions for function names (e.g.
> verb first, obvious names, etc.).
>
Although I wasn't aware that (as of your post) any proposals
had been made, I can summarize my expressed POV succinctly.
I'm *not* proposing names here, for two reasons:
1) Without questioning the value of good naming, I'm more
concerned at the moment with functionality, and am quite
happy to discuss naming issues have subsequently (e.g.
"name follows function")
2) In this discussion (not proposal) among professional
programmers, I think we can talk about ideas that apply
to many cases without having to give specific examples of
each possible application.
That said, here's the POV I was suggesting:
* Allow expressions to ask for the true INDEX? of any series,
* Allow programmers to test that value against whatever
criteria are appropriate in each case, and take the
appropriate actions.
In more detail:
1) It should always be possible to ask for the INDEX? of a
series, and the result should be the actual position of
that reference (whether in bounds or not).
2) It should always be possible to ask for contents from
a series. If the request is out of bounds, the result
should be NONE. This is exactly how PICK, FIND, and
SELECT work currently, AFAIK, with NONE representing the
"no answer" case. This is also similar in idea to the
value of e.g. IF and SWITCH which evaluate to NONE if
the controlling expression/value causes them to gracefully
do nothing.
3) In cases where the series ref may not be in bounds, having
INDEX? behave as in (1) allows us easy options when trying
to retrieve content:
3a) If NONE is an acceptable value in the current case,
simply write the obvious expression (PICK, FIRST, etc.)
3b) If NONE is not an acceptable value in the current case,
(e.g. summing a collection of numbers), then write the
surrounding expression to handle gracefully the
"no answer" case, as in
bonuses: [
"Tom" 25.00
"Myrtle" 50.00
"Alice" 75.00
"Harry" 15.00
]
total: 0
foreach name ["Tom" "Dick" "Harry"] [
total: total + any [select bonuses name 0.00]
]
3c) If the surrounding expression depends on an series
reference having an in-bounds position), then that could
be explicitly tested given (1), as in
here: index? ser-ref
either all [1 <= here here < length? head ser-ref] [
something: first ser-ref
][
; handle the out-of-bounds situation
]
or (using an appropriate definition of IN-BOUNDS? either
as mezzanine or native)
either in-bounds? ser-ref [
something: first ser-ref
][
; handle the out-of-bounds situation
]
either of which seems to me as easy to write/understand as
the present
if error? try [something: first ser-ref] [
; handle the out-of-bounds situation
]
None of these ideas would seem to require more state data in a
series value, nor would they have a negative effect on performance;
in fact ordinal fetches (FIRST, SECOND, et al) would actually be
faster. (AFAIK, but I have no knowledge of the inside details
of the REBOL interpreter ;-)
In overall response to your post, let me just add this.
I'm truly sorry that you seem to have been offended/annoyed by the
discussion. I truly don't feel that you responded to questions
that were raised along the way (why INDEX? should give different
values, why PICK _ 1 and FIRST should not mean the same thing,
etc.) when those questions were raised in a good-faith effort to
understand the intent of past and (apparently forthcoming) REBOL
design. I'm sad that it is so easy to dismiss sincere questions
or concerns with condescending remarks about "theory".
As a working programmer who works with other programmers of
various skill levels, I have little time to spend trying to look
out for special cases (or changes) in behavior of the language I
use (especially the undocumented special cases or changes).
Whenever I can say (or read, or remember for myself) statments like
foo does blah-blah-blah
and know that that's the whole story, it's easier to learn/use FOO
than when the true statement is more like
foo does blah-blah-blah
unless so-and-so, in which case yadda-yadda-yadda, and
unless such-and-such, in which case bow-wow-wow, and
unless you've previously done ...
This is not an issue of "theory". It is an issue of how easy it
is to learn/use a language effectively. REBOL has many useful
qualities and worthwhile ideas. I'd like to see it succeed.
These comments are offered with that goal in mind.
-jn-
