pragma wrote:
> In article <ch2qm2$186l$1@digitaldaemon.com>, Bent Rasmussen says...
> 
>>I see and that argument ties in with Walters argument. If it were not for that argument I would say  that it is no big deal because it doesn't have to scale, as far as I can see; but that's a matter of oppinion. Its also possible to do the other way around, although with near no benefit except symmetry (I'm a sucker for that though)
>>
>>e[i..]
>>e[..j]
>>e[i..j]
> 
> 
> I, for one, love the above syntax simply because it cannot be confused for
> anything else but what its for.  Also, the python-esque negative indicies would
> also work very well for further reducing the need for referencing 'length' in a
> slice operation.
> 
> As nice a shortcut 'length' is in a slice, I have to put my $0.02 in that it
> hurts more than it helps in a lot of cases.  It also leads to some very
> ambiguous code if 'length' is declared elsewhere in the same scope as the slice
> operation. :(
> 
> Walter, thank you for making strides in adding all these great features to this
> language.  With all due respect, I'm looking forward to V0.102. :)

I agree on all counts.  I mourn the lack of a straightforward way to ask for the last n elements, but life will go on.  Further, this syntax doesn't add any magic words to the language, which means that it doesn't close any doors for new syntax come 2.0 time.

 -- andy

On Tue, 31 Aug 2004 21:45:23 -0400, Ben Hinkle <bhinkle4@juno.com> wrote:
>>> The key difference is that "with" is a statement and we need it in an
>>> expression.
>>
>> Do we? can you give me an example?
>
> the things inside the brackets must be expressions. For example in e[length
> - 4 .. length] both "length-4" and "length" are expressions. You can't put
> a statement where D expects an expression.

I see where you're coming from. I was not suggesting adding 'with' inside the [].

> Since that slice expression might appear deep inside another expression it can be slightly painful to rewrite it all into a with statement.

Example, example, example.. please :)
I think using 'with' will not only work, it will give cleaner code too.

> I was surprised that Walter added this "length" sugar but it did generate
> some excitement before.

Me too.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <ch3jgm$1mjq$1@digitaldaemon.com>, Derek Parnell says...
>
>On Wed, 1 Sep 2004 02:25:17 +0000 (UTC), pragma wrote:
>
>> In article <ch2qm2$186l$1@digitaldaemon.com>, Bent Rasmussen says...
>>>
>>>I see and that argument ties in with Walters argument. If it were not for that argument I would say  that it is no big deal because it doesn't have to scale, as far as I can see; but that's a matter of oppinion. Its also possible to do the other way around, although with near no benefit except symmetry (I'm a sucker for that though)
>>>
>>>e[i..]
>>>e[..j]
>>>e[i..j]
>
>Using this scheme, how does one specify the 2nd last element, such as e[i..length-1]?

I think it would be:

e[i..-1]


Sean

In article <ch3bud$1h94$1@digitaldaemon.com>, pragma says...
>
>In article <ch2qm2$186l$1@digitaldaemon.com>, Bent Rasmussen says...
>>
>>I see and that argument ties in with Walters argument. If it were not for that argument I would say  that it is no big deal because it doesn't have to scale, as far as I can see; but that's a matter of oppinion. Its also possible to do the other way around, although with near no benefit except symmetry (I'm a sucker for that though)
>>
>>e[i..]
>>e[..j]
>>e[i..j]
>
>I, for one, love the above syntax simply because it cannot be confused for anything else but what its for.  Also, the python-esque negative indicies would also work very well for further reducing the need for referencing 'length' in a slice operation.
>
>As nice a shortcut 'length' is in a slice, I have to put my $0.02 in that it hurts more than it helps in a lot of cases.  It also leads to some very ambiguous code if 'length' is declared elsewhere in the same scope as the slice operation. :(
>
>Walter, thank you for making strides in adding all these great features to this language.  With all due respect, I'm looking forward to V0.102. :)
>
>- Pragma
>EricAnderton at (sig[0..]) yahoo dot com
>

e[i...]
e[...j]
e[i..j]

?

In article <ch2fml$126h$1@digitaldaemon.com>, antiAlias says...

>Permit me to ask the obvious question: why was this changed in the first place?

Poor Walter. He can't win. :( I rather gather that this feature was introduced because enough people on this newsgroup asked for it, or at least for something similar.

Further, this isn't a bug, since the feature works exactly as described in the manual.

However, I'm all in favor of having the compiler help us to find user-bugs at compile time, and to this end, I do think there is room for manoeuvre here. So here are some (mutually exclusive) options - any one of them would solve the problem. They are listed in order of my preference (most preferred first):


1) It shall be considered a compile-time error for the new use of "length" to eclipse a local variable called "length". (This forces the user to rename their conflicting variable).

2) Use the symbol "$" instead of the identifier "length". (so "e[length-1..length]" becomes "e[$-1..$]"). Note that "$" is a good choice, as it already means "end of string" in a regular expression.

3) Leave things exactly as they are now. If you screw up, it's your problem.

4) Make "length" a reserved word. This prevents users from having variables of this name.

5) Allow the keyword "with" (or some other keyword) to refer to the array, when
used within a subscript expression (so "e[length-1..length]" becomes
"e[with.length-1..with.length]".

6) Remove the feature altogether

There are probably others, but that list will do me. I vote for (1), with (2) as
my second choice.

Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ch3uu3$1u3e$1@digitaldaemon.com...
> In article <ch2fml$126h$1@digitaldaemon.com>, antiAlias says...
>
> >Permit me to ask the obvious question: why was this changed in the first place?
>
> Poor Walter. He can't win. :( I rather gather that this feature was
introduced
> because enough people on this newsgroup asked for it, or at least for
something
> similar.
>
> Further, this isn't a bug, since the feature works exactly as described in
the
> manual.
>
> However, I'm all in favor of having the compiler help us to find user-bugs
at
> compile time, and to this end, I do think there is room for manoeuvre
here. So
> here are some (mutually exclusive) options - any one of them would solve
the
> problem. They are listed in order of my preference (most preferred first):
>
>
> 1) It shall be considered a compile-time error for the new use of "length"
to
> eclipse a local variable called "length". (This forces the user to rename
their
> conflicting variable).
>
> 2) Use the symbol "$" instead of the identifier "length". (so
> "e[length-1..length]" becomes "e[$-1..$]"). Note that "$" is a good
choice, as
> it already means "end of string" in a regular expression.
>
> 3) Leave things exactly as they are now. If you screw up, it's your
problem.
>
> 4) Make "length" a reserved word. This prevents users from having
variables of
> this name.
>
> 5) Allow the keyword "with" (or some other keyword) to refer to the array,
when
> used within a subscript expression (so "e[length-1..length]" becomes "e[with.length-1..with.length]".

I would go with the "with" because it is the most general solution

e[e.length-5..e.length];
e.sort();

becomes
with(e)
{
    this[this.length-5..this.length];
    this.sort();
//or instead of this something like "obj"

}

> 6) Remove the feature altogether
>
> There are probably others, but that list will do me. I vote for (1), with
(2) as
> my second choice.
>
> Arcane Jill
>
>

In article <ch44vg$21cd$1@digitaldaemon.com>, Ivan Senji says...

>> 5) Allow the keyword "with" (or some other keyword) to refer to the array,
>when
>> used within a subscript expression (so "e[length-1..length]" becomes "e[with.length-1..with.length]".
>
>I would go with the "with" because it is the most general solution
>
>e[e.length-5..e.length];
>e.sort();
>
>becomes
>with(e)
>{
>    this[this.length-5..this.length];
>    this.sort();
>//or instead of this something like "obj"
>
>}

That is not what I suggested. Please read again. (In fact, I was merely re-iterating Ben's earlier suggestion there). Your suggestion appears to be very similar to the status quo.


To recap the six options, all of which refer to the evaluation of a subscript or slice /expression/:

1) It shall be considered a compile-time error for the new use of "length" to eclipse a local variable called "length". (This forces the user to rename their conflicting variable).

This is definitely my favorite. It means that this will compile normally:

#    {
#        int length = 5;
#        f(length);
#    }
#    {
#        ubyte[] array = new ubyte[10];
#        array[length-1] = 3;
#    }

but this will not:

#    {
#        int length = 5;
#        f(length);
#        ubyte[] array = new ubyte[10];
#        array[length-1] = 3;          // error - length eclipses local variable
#    }

Easy. Same syntax as now. All errors found. If this can be done then further complications and changes of syntax can be completely avoided. For what it's worth, here are the other suggestions:


2) Use the symbol "$" instead of the identifier "length". (so "e[length-1..length]" becomes "e[$-1..$]"). Note that "$" is a good choice, as it already means "end of string" in a regular expression.

3) Leave things exactly as they are now. If you screw up, it's your problem.

4) Make "length" a reserved word. This prevents users from having variables of this name.

5) Allow the keyword "with" (or some other keyword) to refer to the array, when
used within a subscript expression (so "e[length-1..length]" becomes
"e[with.length-1..with.length]".

6) Remove the feature altogether

I have to say, I don't like (6) at all. I would like to see this feature kept in
some form.

Jill

> I have to say, I don't like (6) at all. I would like to see this feature
> kept in
> some form.

(1) does look like the most pragmatic solution.

> e[i...]
> e[...j]
> e[i..j]
>
> ?

It means the same as

e[i...e.length]
e[0...j]

I wohn't tell what the last one means. :-)

In article <ch4b7u$24sq$1@digitaldaemon.com>, Arcane Jill says...
>
>1) It shall be considered a compile-time error for the new use of "length" to eclipse a local variable called "length". (This forces the user to rename their conflicting variable).

"length" might not be a local, it might be a class member or even global, and in some cases you can't change that. Personally I don't mind the way it works now, but perhaps a special symbol like $ would be safer. (OTOH I don't want my code to look like Perl ;-)

Nick