Hi Louis —
Thanks for the quick responses!
With respect to your last two scores:
1 - Likely some _very_ subtle bugs that are a nightmare to debug.
...
4 - Honestly, the time taken to introduce someone else to the code base
is sig...
I've been working through these proposed changes in our module code and
(now 10,000+) test cases and find that they're not as bad as you (and for
awhile, I) worried about because bounds checking points out most of the
cases that are problematic (often at compile-time for tuples, but if not,
at execution time). The main cases that get problematic are a case where
a tuple has more than one element, is indexed using myTuple(1), and then
none of the other elements are ever indexed.
I've also been able to make most of the changes without being semantically
familiar with the code in question. The bounds-checking points out the
problematic case, I find the tuple expressions used in the related code
and update them, then propagate the changes to other similar patterns or
uses of the variable(s) in the code. So I'd be happy to help update CHGL
or other code if it would be useful (or to use them as acid tests on my
branch before merging if you can make suggestions for how to test that
they still work).
While I've got you, how's school going this year?
Thanks again,
-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
On Mon, 4 Nov 2019, Louis Jenkins wrote:
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
7 - It makes the most sense and feels the most natural for all indexing to
either be A) configurable to specify lower bounds and upper bounds, or B)
Matches every other language which cannot provide configurable lower-bounds.
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
4 - I am supportive of the change, as I believe it should be this way; however
I have my reservations as stated in the next question.
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.
1 - Likely some _very_ subtle bugs that are a nightmare to debug.
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!
4 - Honestly, the time taken to introduce someone else to the code base is
significantly longer than the time to just do it myself.
On 11/4/19 1:13 PM, Brad Chamberlain wrote:
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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchapel-lang%2Fchapel%2Fissues%2F12988&data=02%7C01%7C%7C2e39731bfa0d4f7c08b908d76152c244%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637084880385639528&sdata=h%2FAVoV1O3Nu6Bq1ZNeIpskZD3II5UQgzqA%2BdKZHRZ3I%3D&reserved=0
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]<mailto:[email protected]>
https://nam10.safelinks.protection.outlook.com/?url=www.cray.com&data=02%7C01%7C%7C2e39731bfa0d4f7c08b908d76152c244%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637084880385649537&sdata=1%2B47SG6yGimjTRqf5bLypzGzadLQJZS5g02TDny%2FzpA%3D&reserved=0
_______________________________________________
Chapel-developers mailing list
[email protected]<mailto:[email protected]>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fchapel-developers&data=02%7C01%7C%7C2e39731bfa0d4f7c08b908d76152c244%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637084880385659538&sdata=pU6tSYoFgz%2BmZL2YAU8vBRR1P6nvEd8kHluu0woG9AI%3D&reserved=0
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
