Both IAL and ALGOL 60 allowed arrays with arbitrary lower and upper
subscript bounds, and allowed subscript bounds to be defined by
integer expressions.
http://www.cs.virginia.edu/~mpw7t/cs655/pos2.html
ALGOL 68 was designed to be an improvement upon ALGOL 60. In ALGOL 60,
arrays could be multi-dimensional, they could be dynamically sized,
and their lower bound index could be non-zero [1].
Fortran doesnāt care much either. Thereās a convention for starting
at 1, but the language allows you to specify an arbitrary index
range for your arrays.
Perl copied that misfeature, though it defaults to zero, in the hopes
of attracting Fortran programmers. What they learned was that it
breaks way too much. Iām pretty sure itās being removed in Perl 6.
On Tue, Jul 17, 2007 at 10:43:35PM +0900, Adrian H. wrote:
Perlās misfeature is pretty different - itās a global rather than a
per-array thing. Being able to say "this particular array has indices
-10 -> 10 is considerably more useful than saying āevery array starts
at -10ā
News to me. Would you point me at more information on the topic,
please?
ALGOL 58 - Wikipedia
Both IAL and ALGOL 60 allowed arrays with arbitrary lower and upper
subscript bounds, and allowed subscript bounds to be defined by
integer expressions.
I wonder how C got saddled with a fixed lower limit of 0 then. It must
have been a simplification somewhere in the chain from Algol - CPL -
BCPL - B - C.
http://www.cs.virginia.edu/~mpw7t/cs655/pos2.html
ALGOL 68 was designed to be an improvement upon ALGOL 60. In ALGOL 60,
arrays could be multi-dimensional, they could be dynamically sized,
and their lower bound index could be non-zero [1].
Algol 68 was a truly marvelous language that somehow never caught on.
I wonder how C got saddled with a fixed lower limit of 0 then. It must
have been a simplification somewhere in the chain from Algol - CPL -
BCPL - B - C.
In C the expression array[n] is actually just syntactic sugar for
*(array + n). Literally. I havenāt tried in years, but the following
is supposed to be legitimate: n[array]. Great for obfuscating code.
If thatās how youāre going to perform array lookups, then your array
indices have to start from 0.
Ruby aims to be a human friendly programming language that embodies the
principle of least surpriseā¦
The pebble in the Ruby shoe is the counter-intuitive use of indexing of
elements of arrays, strings, etc., from 0 to n-1 instead of the more
natural 1 to n.
With 50+ years of collective experience, it seems clear that zero-
based arrays lead to the simplest code.
On Wed, 2007-07-18 at 16:42 +0900, Ronald F. wrote:
To contrast with, the IMO most unpleasant way of approaching the index
origin was done in APL. There, you could set the system variable _IO
to either 0 or 1 (no other value accepted)
Perl has this too, though itās called $[.
Obviously, it isnāt normally used and people assume the default value of
0.
In C the expression array[n] is actually just syntactic sugar for
*(array + n). Literally. I havenāt tried in years, but the following
is supposed to be legitimate: n[array]. Great for obfuscating code.
This indeed works, and consequently funny variations such as
(n1-n2)[n2+array] work too. It is obfuscating not so much because
it were not easy to understand, but because we simply are not used to
see it written that way (because other languages usually do it in
the other way around).
To contrast with, the IMO most unpleasant way of approaching the index
origin was done in APL. There, you could set the system variable _IO
to either 0 or 1 (no other value accepted), which rules whether array
the index of any array is from now on counted from 0 or from 1.
True, you could localize this setting in a function, but at least
in original APL (I donāt know about APL2), these were not truly
ālocalā variables like in Ruby, but more like those ālocal globalā
variables you would for example declare in Perl by writing
ālocal $v=ā¦;ā, with the consequence that they the change to _IO
would be visible in all functions called from within the function
which had ālocallyā reset the index origin. This has the consequence
that if you write any reusable function for APL (such as a library),
you must use the value of this variable for indexing. For example,
in order to access the Nth element of an array A, you would write
something like A[N+_IO-1].
BTW: Though I - like most programmers - find it most convenient counting
arrays from zero, there are cases where I would find it more natural
if I could choose the upper and lower bound of an array by myself (as
it is done in languages such as Ada). Such an approach would work well
in a statically typed language (where you can in principle look up
the variable declaration), but would make understanding a program
unnecessarily hard in dynamic languages such as Ruby.
On Wed, 2007-07-18 at 16:20 +0900, kevin cline wrote:
The pebble in the Ruby shoe is the counter-intuitive use of indexing of
elements of arrays, strings, etc., from 0 to n-1 instead of the more
natural 1 to n.
With 50+ years of collective experience, it seems clear that zero-
based arrays lead to the simplest code.
Thatās been my personal experience, too ā pretty much the only thing
1-based indices make simpler is getting the last element of an array
given its size; everything else seems to get more complex.
I do not like categorical statements, but this one might be the
exception that confirms the rule.
+1 (or was that +0
Lets not forget also that doing things for the sake of being different
help no
one. I for one must work in multiple languages. I still havenāt forgiven
Matz
for the whole, ā0 is trueā thing.
True! It seems that the Perl community (reasonably) assumes
that whoever fiddles with $[, so everyone assumes it to be
0, while in the APL world it was more common to expect that everyone
might change _IOā¦
I do not like categorical statements, but this one might be the
exception that confirms the rule.
+1 (or was that +0
Lets not forget also that doing things for the sake of being different help no
one. I for one must work in multiple languages. I still havenāt forgiven Matz
for the whole, ā0 is trueā thing.
That is the single best feature of Ruby once you got used to it ā
with āā is true!!!
IMHO of course.
Robert
-mental
Well ā¦ the reason the first major programming language, FORTRAN, used
1-based indexing is that it was designed for scientific computing, which
uses matrices extensively. And a matrix in a textbook or research paper
almost always has row and column indices ranging from 1 to N. So ā¦ one
of the things 1-based indexing makes simpler is thinking about matrices.
Assembly language programming, at least on binary machines, is a lot
more natural with 0-based indexing, since thatās the way the hardware is
laid out.
based arrays lead to the simplest code.
ā¦unless there is a lot of exposure of nominal index values to the end
user, in which case the additional effort of doing that may incur more
complexity than is saved by using 0-origin internally.
Well ā¦ the reason the first major programming language, FORTRAN, used
1-based indexing is that it was designed for scientific computing, which
uses matrices extensively. And a matrix in a textbook or research paper
almost always has row and column indices ranging from 1 to N. So ā¦ one
of the things 1-based indexing makes simpler is thinking about matrices.
Assembly language programming, at least on binary machines,
ā¦all the decimal machines I can recall, tooā¦
is a lot
more natural with 0-based indexing, since thatās the way the hardware is
laid out.
PL/I implementations have historically regarded the address of an array
as being where the (0, 0, 0ā¦) element would be, even if one doesnāt
exist, to reconcile these two.
Lets not forget also that doing things for the sake of being different
help no one. I for one must work in multiple languages. I still havenāt
forgiven Matz for the whole, ā0 is trueā thing.
but but butā¦
The original idea of zero as true, if memory serves, is that a function
can return a result based on whatever it was doing. It was assumed that
there was one way to get everything to run right but many ways to fail.
SO, if you have zero as the true and everything else as both an
pass/fail indicator AND telling you just what the problem was, then true
= zero makes a good deal of sense.
