Luís Marques wrote:
> In article <e0s6a7$1sbs$1@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.

please, can anybody explain me, wich "performance penalty" mentioned in this thread? how it come?

In article <e0tdh2$bsn$1@digitaldaemon.com>, novice2 says...
>please, can anybody explain me, wich "performance penalty" mentioned in this thread? how it come?

When array bounds checking is disabled, all the CPU has to do is something like:

value = *(&array_contents + (index * element size));

The index is just added as an offset (times the element size, which can be really fast if it's a multiple of 2). When you add bounds checking or negative indexes, other operations must be performed. For bounds checking a conditional jump must be issued (conditional jumps can be expensive for performance -- on inner loops -- plus they add footprint). For negative indexes the corresponding positive offset must be calculated before accessing the array index. Under some circunstances the compiler could optimize that, when it would be possible to do the calculation at compilation or to assume the index was a unsigned integer. I suppose there's no general arithmetic algorithm for all cases (without conditional jumps).

I guess that should be it, but others should know more about such matters.

Luís Marques

Thanx, Luís Marques for reply, but...

>When you add bounds checking or negative
>indexes, other operations must be performed. For bounds checking a conditional

it is not depends on syntax or index sign. this check must be performed (if
enabled), either positive or negative index.
Even more: we all know, source code and compiler output is not the same. and
source code with negative indexes or other index syntax will be compiled into
the same cpu operations, if it means the same.

>inner loops -- plus they add footprint). For negative indexes the corresponding positive offset must be calculated before accessing the array index. Under some

this is not true. when we use other syntax for some operations the compiler output will be the same. even if we replace some several operations with one syntax construction compiler can generate more optimized code.

i just want to say, IMHO, all changes in index/slicing syntax will change compiler only. not generated binary.

In article <e0tvba$1aav$1@digitaldaemon.com>, novice2 says...
>i just want to say, IMHO, all changes in index/slicing syntax will change compiler only. not generated binary.

Actually I don't think that can be true. That would only be the case if the indexes were defined at compilation time. Assuming positive indexes only, the following code...

int index = get_int_from_user();
value = array[index];

could be translated into:

value = *(&array_contents + (index * element size));

If we allow negative indexes then that doesn't work. "index" is computed at runtime so the code generated must change to allow that. At least that's the way I see it.

About bounds checking, I didn't mean to imply it depends on the syntax.

Luís Marques

In article <e0s6a7$1sbs$1@digitaldaemon.com>, Norbert Nemec says...
>	somearray[x%$,y%$,z%$]

Before asking some more questions, how could you please give me a working example for this?

Thanks,
Luís Marques

novice2 wrote:
> Thanx, Luís Marques for reply, but...
> 
> 
>> When you add bounds checking or negative indexes, other operations
>> must be performed. For bounds checking a conditional
> 
> 
> it is not depends on syntax or index sign. this check must be
> performed (if enabled), either positive or negative index. Even more:
> we all know, source code and compiler output is not the same. and source code with negative indexes or other index syntax will be
> compiled into the same cpu operations, if it means the same.
> 
> 
>> inner loops -- plus they add footprint). For negative indexes the
>> corresponding positive offset must be calculated before accessing
>> the array index. Under some
> 
> 
> this is not true. when we use other syntax for some operations the
> compiler output will be the same. even if we replace some several
> operations with one syntax construction compiler can generate more
> optimized code.
> 
> i just want to say, IMHO, all changes in index/slicing syntax will
> change compiler only. not generated binary.

Well, we have two separate cases. First, if the array size is known at compile time, then all of this can be take care of without runtime penalty. Second, if we are talking about dynamic arrays, then it does make a difference whether we allow indexing from the end of the array.

Luís Marques wrote:
> In article <e0s6a7$1sbs$1@digitaldaemon.com>, Norbert Nemec says...
> 
>>	somearray[x%$,y%$,z%$]
> 
> 
> Before asking some more questions, how could you please give me a working example for this?

No, because multidimensional arrays do not exist yet, but are still in the planning phase.

I've been spending some hours working on reworking the proposal lately, but I have nothing new finished yet.

The 2-years-old version of the proposal can still be found at:
	http://homepages.uni-regensburg.de/~nen10015/documents/D-multidimarray.html

(It is quite outdated in the details, but should at least give an idea
of where it may be going.)

Norbert Nemec wrote:
> Luís Marques wrote:
>> In article <e0s6a7$1sbs$1@digitaldaemon.com>, Norbert Nemec says...
>>
>>> 	somearray[x%$,y%$,z%$]
>>
>> Before asking some more questions, how could you please give me a working
>> example for this?
> 
> No, because multidimensional arrays do not exist yet, but are still in
> the planning phase.
> 
> I've been spending some hours working on reworking the proposal lately,
> but I have nothing new finished yet.

I'm looking forward to seeing it. Could really be a killer feature.

> The 2-years-old version of the proposal can still be found at:
> 	http://homepages.uni-regensburg.de/~nen10015/documents/D-multidimarray.html
> 
> (It is quite outdated in the details, but should at least give an idea
> of where it may be going.)

>>i just want to say, IMHO, all changes in index/slicing syntax will change compiler only. not generated binary.
>
>Actually I don't think that can be true. That would only be the case if the indexes were defined at compilation time. Assuming positive indexes only, the following code...

but programmer defines algo - sequence of some operations.
we should compare equal code for currnet syntax and new syntax.
equal code - with equal results.

just imaginary example:

task: get 3rd item from end in array;
new synatx: b = a[-3];
old syntax: b = a[length-3];

only now we can compare, wich actions will be performed in runtime, and guess, will be it different or not.