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 `[1..0] string`)
* numberings of things like dimensions (e.g., `myDom.dim(0)` 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 [email protected] www.cray.com_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
