[My apologies for the seemingly duplicate mail. This is a resend to
address two dumb typos in the original version. Thanks to Engin for
pointing them out. -Brad]
Hi Chapel programmers —
Executive Summary: In cases where the language, rather than programmer,
determines indices, we're considering a proposal to change Chapel from using
1-based indexing to 0-based indexing, and we are interested in your thoughts on
the proposal.
The rest of this note is organized as follows:
* Overview of the change:
* Indexing cases that won't need to change
* Indexing cases that may or will need to change
* Questions we'd like you to answer
* Further background for those who are interested
Indexing cases that won't need to change
----------------------------------------
The "in cases where the language chooses..." qualification above is crucial
because the most common places in Chapel that deal with indexing require the
programmer to specify low and high bounds:
* ranges (e.g., `0..n-1` vs. `1..n` vs. `-3..3`)
* domain values (e.g., `{1..n, 0..n-1, -3..3}`)
* array types (e.g., var `A: [1..n, 0..n-1, -3..3] real;`)
Such cases would not require any changes in user code if we were to make the
proposed change.
Indexing cases that may or will need to change
----------------------------------------------
So then what cases do default to 1-based indexing today?
* tuples (e.g., today `myTuple(1)` returns the first element; in the
proposal, `myTuple(0)` would)
* strings (e.g., given `s = 'hello'`, today s[1] is 'h'; in the
proposal, s[1] would be `e`)
* lists (e.g., myList[1] returns the first element in the list today;
in the proposal, myList[0] would)
* array types inferred from literals (e.g., `var A = ["hi", "there"];`
results in A having type `[1..2] string` today; in the proposal, it
would have type `[0..1] string`)
* numberings of things like dimensions (e.g., `myDom.dim(1)` returns
information about the first dimension of a domain today; in the
proposal, `myDom.dim(0)` would).
Note that many use cases for these types are independent of the indexing scheme
used. For example, tuples can be decomposed using:
var (x, y) = myTuple;
rather than `myTuple(i)`.
Lists and strings can be iterated over without using indexing:
for elem in myList do ...
Indices can be queried and used without ever thinking about their numerical
values:
var pos = myString.find("/");
writeln(myString[pos..]);
etc.
Questions we'd like you to answer
---------------------------------
Here are some questions we'd like your thoughts on; you can either mail your
responses back to me or to the list(s) as you prefer. Each question asks you
to rate something on a scale of 1-7, though we'd also be interested in any
arguments or thoughts behind your numerical score.
Q: If we were designing Chapel from scratch, or you were approaching it
for the first time today, would you be happiest if its indexing was
1-based or 0-based?
1 = I'd be happiest if it were 1-based
...
4 = It wouldn't really matter to me
...
7 = I'd be happiest if it were 0-based
Q: Given that Chapel is not brand new, how enthusiastic is your support
for making it 1-based or 0-based today?
1 = I feel strongly that it should remain 1-based
...
4 = It wouldn't really matter to me
...
7 = I feel strongly that it should change to 0-based
Q: How much do you worry about the impact such a change would have on
Chapel code that you've already written?
1 = Very worried: I expect the impact to be significant and would
not be enthusiastic about updating my code.
...
4 = Eh... I don't think this would be a big deal
...
7 = Not at all worried: I expect the impact to my code to be minimal
and/or I support the proposal strongly enough that I think any pain
would be worth it.
Q: If we were to make the change and you are worried about it, would it
be possible/helpful if we were to help update your code?
1 = No, not possible: I'm not permitted to share my code with you
...
4 = It'd be possible, but I don't think I'd need the help, thanks
...
7 = It'd be possible and very helpful, thanks!
Further Background for those who are interested
-----------------------------------------------
When Chapel launched, we thought hard about whether to make the language
0-based or 1-based, and worked hard to make it as neutral to either indexing
scheme as possible. This is why Chapel's ranges, domains, and array types
require low and high bounds to be specified rather than relying on a default
lower-bound. However, as indicated above, in some cases we had to make a
choice (tuples arguably being the most significant and pervasive example; lists
being the most recent).
We chose 1-based indexing in these cases because, at that time, we were
thinking primarily in terms of programmers coming to Chapel from C/C++, Java,
Fortran, and Matlab, where the first two groups are 0-based and the latter two
are 1-based. We chose to go with 1-based programming fairly arbitrarily, on
the argument that counting from 1 is more natural to most people; and being a
language focused on productivity, we wanted to maximize our appeal.
Since that time, many other languages have come along and/or gained significant
popularity and mindshare. Python clearly stands out from the crowd and is
0-based. Rust, Swift, and Go are all (arguably) 0-based as well. The
increasing dominance of 0-based languages suggests that we are arguably on the
wrong side of history. Julia is one of the few recent exceptions that is
1-based and its popularity demonstrates that you can be 1-based and successful.
As you may know, we are working towards an upcoming "Chapel 2.0" release whose
goal is to freeze a set of core language features to prevent backwards breaking
changes in future Chapel releases. As part of this effort, the question of 1-
vs. 0-based indexing came up since it's something we'd want to change before
Chapel 2.0 if we were ever planning on it.
One of the things that forced the conversation is that while Chapel is 1-based
when the language decides, there are some arrays built into the language that
are 0-based, such as the Locales array and the argv-style array provided to
main(). On one hand, this could be argued to be consistent with the language
since the language lets arrays have any lower bound; and a lower bound of 0 is
arguably most natural for both of these cases. On the other hand, these arrays
are about as built into the language as anything, so perhaps they should be
1-based as well?
Reconsidering our original argument, while 1-based programming is arguably most
natural to humans, 0-based indexing is arguably much more productive and
familiar to most programmers, and realistically, Chapel's target audience is
not "humans who don't program" so much as "those who do and are looking for a
productive, parallel, scalable alternative to what they're using today."
And again, given that the most common cases of indexing (ranges, domains, and
array types) support any low bound and don't have a default, programmers who do
prefer 1-based programming can still (largely) live in that world. As a
specific example, I have no expectation that our LinearAlgebra library would
switch to using 0-based matrices if we were to make this language change
because 1-based indexing is arguably most typical and natural for that context.
There is a GitHub issue on this topic, but I've avoided mentioning it until now
because I wanted to lay out the topic as above, whereas the GitHub issue is a
bit more scattered. That said, it's another place you can read or comment
about this topic:
https://github.com/chapel-lang/chapel/issues/12988
Thanks for your feedback and thoughts on this,
-Brad
---
Brad Chamberlain Principal Engineer
Cray, a Hewlett Packard Enterprise company
901 Fifth Ave, Suite 1000 | Seattle, WA 98164
+1-206-701-2077 br...@cray.com www.cray.com_______________________________________________
Chapel-users mailing list
Chapel-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/chapel-users
