zero based indexing
[1/2] from: deadzaphod::flyingparty::com at: 6-Jul-2001 3:02
I'm a bit confused by the heated arguments about series indexing in rebol.
rebol does not provide an array subscript operator, so virtually all series
access is done via functions. why not just create a set of new functions
(with different names so we don't break anything) that use zero (or whatever
you want) as a base, and you can just use those instead of
pick/at/poke/index? in your scripts, without needing any change or patch to
rebol itself.
here's some examples (with names based off the normal functions) for zero
based indexing:
pick': func [[throw] l i][first at l i + 1]
at': func [[throw]l i][at l i + 1]
poke': func [[throw] l i d ][change/only at' l i :d l]
index': func [[throw] l ][-1 + index? l]
what would an internal change to rebol do for us that this doesn't? (other
than the improved speed by making these native! functions) (I realize I'm
probably missing something important, judging by the length of this thread)
Cal
[2/2] from: joel:neely:fedex at: 6-Jul-2001 12:01
Hi, Cal,
Cal Dixon wrote:
> ... why not just create a set of new functions ... and you
> can just use those instead of pick/at/poke/index? ...
> what would an internal change to rebol do for us that this
> doesn't? (other than the improved speed by making these
> native! functions)
>
It wouldn't have to be an "internal change". As you implied, it
would be quite satisfactory simply to have an alternative set
of functions in addition to the ones currently available.
However, because access to structures is so fundamental to
(and pervasive in) programs that make non-trivial use of those
structures, there could be a *substantial* performance penalty
to writing and using mezzanine-like wrappers whose main
raison-d'etre was adding or subtracting one. If RT were to offer
these capabilities without performance penalty (e.g. as additional
natives) that would solve the problem nicely.
As for the agonizing length (and temperature) of the discussion,
I must confess my own measure of bafflement.
My experience in dealing with technology vendors goes back to
the early 70's, when I was a subgroup officer in CUBE, the
international users' group for Burroughs computers. We (the
users' group as a whole) had very good experience with the kind
of dialog in which we explained our problems, limitations, or
difficulties, and the appropriate technical and/or product
management folks would respond with suggested work-arounds or
descriptions of new features which they would implement to
provide solutions.
These dialogs took place on a regularly-scheduled basis, and
were taken seriously by all parties. (Since this was before
the wide-spread availability of the Internet, the process
took place via meetings scheduled every 6 months. ;-)
It was quite common for Burroughs to provide better (faster,
more efficient, more elegant, etc.) solutions than those
originally proposed or suggested by the users. All in all,
the process was highly satisfactory.
-jn-
___________________________________________________________________
The purpose of computing is insight, not numbers!
- R. W. Hamming
joel'dot'neely'at'fedex'dot'com