Unidirectional indexing in the CLR language?

I am working on a very high-level domain language that analyzes data. There is a virtual, uniform agreement that unidirectional indexing is a scientific transition. Of course, programmers hate this discrepancy, but almost all of our users use x [i] to denote element i, not element i-1.

Are there any design principles that can be used to preserve any reasonable history of interacting with the CLR? I meant that if we automatically translate the System.Collections space with options based on one, together with our C # based APIs, we should be 90% of that. But I'm not sure. For example, should I automatically reinstall the IList interface? But what happens if the C # API implements CustomRemove (zeroBasedIndex)?

Is there anything else we can do to alleviate this painful mismatch? How far should we go in creating System.Collections based on.

Finally, are there any examples of CLR-based languages?

+4
source share
2 answers

Option 1: Record an entry in your list. Set element 0 to zero and all logical indices start at 1.

Option 2. Create your own wrapper for the list and get its getter and increase the index for you.

+2
source

VB is used to specify the base index of arrays, but this function has never been implemented in VB.NET. However, you can create 1-based arrays in the CLR, but they will be a little slower and largely incompatible with other CLR languages.

+1
source

Source: https://habr.com/ru/post/1337079/


All Articles