Array indexing and slicing

[Norbert Nemec]

Luís Marques wrote:
> In article <e0s6a7$1sbs$1 at digitaldaemon.com>, Norbert Nemec says...
> 
>>b) The $ is even more powerful than Python-syntax in at least one very
>>interesting way:
>>	somearray[x%$,y%$,z%$]
>>is the most beautiful solution I ever saw for the common problem of
>>periodic boundaries!
> 
> 
> Yes, that one is very nice.
> 
> 
>>you mixed this up in your examples bringing in a -2 somewhere.
> 
> 
> Thanks, I noticed it later.
> 
> 
>>I call "omissive indices" only "[.." instead of "[0.." and "..]" instead
>>of "..$]". Obviously these cover only the trivial corner cases and the
>>syntax cannot naturally be extended to anything beyond these.
> 
> 
> How would you extend it with $?

Sorry, I was not very clear: With "extending" I meant doing something
like "..$-3]". What I wanted to say is: an omissive end-index "..]"
would be a nice shorthand for "..$]", but omissive indices are not a
real alternative to the discussed alternatives that allow arithmetics.

> Still thinking, then, couldn't this work:
> 
> somearray[x%length,y%length,z%length]
> 
> length would evaluate differently for each dimension of the array.
> The only advantage would be $ being shorter (somearray[0..] would work for the
> simpler cases)

Putting Dereks answer in different words: The parser is built upon the
assumption that every "word" is either a "keyword" or an "identifier" at
all times during the compilation process

Making "length" a keyword would, in principle, be a solution, because
one could in principle pack in any special meaning that is needed.
However: "length" could then not be a property any more and could not be
used as variable name or anything else.

Leaving "length" an identifier, one would have to find a way to give it
the special meaning it needs. In any case, this would be problematic,
because it might always override a variable "length" that is defined in
the surrounding namespace.

The "$" solution is very much like the "keyword" solution from the
compiler perspective, but it does not collide with any existing code.