May 11, 2004
Phill wrote:

>Im not with you, you can already do this:
>
> test[0..test.length - 10];
>  
>
People have been requesting a $ symbol to be used as length.  I believe it would be better to have a more generic idea that  uses words instead of ugly symbols.

test[0..length - 10];

Is shorter and quite readable.  It's like doing:

with (test) { test[0..length-10]; }

I would imagine it could save a lot more typing in UDT's ie:

class Array
{
...    stride(int, int) {...}
...    opIndex {...}
}

Array obj(10, 10);

= obj[obj.stride(0, obj.find(10)) .. obj.stride(2, 10)][obj.stride(0, 10) .. obj.stride(1, 3)] ;

As opposed to:

= obj[stride(0, find(10)) .. stride(2, 10)][stride(0, 10) .. stride(1, 3)] ;

or with opCall

= obj[(0, find(10)) .. (2, 10)][(0, 10) .. (1, 3)] ;

Actually you could even do this:

= obj[(10, 10)]; //Almost rectangular array form (make the brackets optional and you'd have it)

Ok a bit overboard but you get the idea.

Another advantage of this technique is that its generic.  It's easily to modify one name at the start rather then 3 or 4 entries, which is a good maintenance helper.

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:c7npt6$2c59$1@digitaldaemon.com...
>  
>
>>Just a thought with slices.  What about if the namespaces became
>>optional inside the square brackets (ie like a with statement).
>>
>>ie
>>= test[0..length];
>>
>>instead of:
>>= test[0..test.length];
>>
>>Then you could also do negative versions like:
>>
>>= test[0..length-10];
>>
>>Since we use length in slices all the time, this would be handy syntax
>>sugar.
>>
>>This would also apply to UDT's.
>>
>>--
>>-Anderson: http://badmama.com.au/~anderson/
>>    
>>
>
>
>  
>


-- 
-Anderson: http://badmama.com.au/~anderson/
May 11, 2004
On Tue, 11 May 2004 08:20:09 +0800, J Anderson wrote:

> Phill wrote:
> 
>>Im not with you, you can already do this:
>>
>> test[0..test.length - 10];
>> 
>>
> People have been requesting a $ symbol to be used as length.  I believe it would be better to have a more generic idea that  uses words instead of ugly symbols.

Hmmmm....ugly symbols....

> test[0..length - 10];

test begin slice 0 to length minus 10 end slice end statement

Starts to look a bit COBOL-like now ;-)


-- 
Derek
11/May/04 11:37:39 AM
May 11, 2004
In article <c7p18a$17t5$1@digitaldaemon.com>, J C Calvarese says...
>
>J Anderson wrote:
>> Just a thought with slices.  What about if the namespaces became optional inside the square brackets (ie like a with statement).
>> 
>> ie
>> = test[0..length];
>
>That's a clever idea, but I'm afraid it'd lead to subtle errors. What if you meant test2.length? You won't get a compile error. If you're lucky, you'd get a runtime error. If you're unlucky, you'd just get the wrong result (and might not even realize it's the wrong result).
>
>But using a symbol to represent this idea would be vastly "safer":
>  = test[0..$length];
>or
>  = test[0..$];
>
>My 2 cents.
>
>> 
>> instead of:
>> = test[0..test.length];
>> 
>> Then you could also do negative versions like:
>> 
>> = test[0..length-10];
>> 
>> Since we use length in slices all the time, this would be handy syntax sugar.
>> 
>> This would also apply to UDT's.
>> 
>
>
>-- 
>Justin (a/k/a jcc7)
>http://jcc_7.tripod.com/d/

Or an even more subtle source of confusion.
Suppose I have the following (contrived example):

int[] bob( int[] spam )
{
int length = 20;
return spam[6..length]
}

Which 'length' would be referred to? How would I specify the function-scope variable length instead of the array property length?

If you want to use 207 class functions/members in array indices, why not wrap it in a with block?

That said, I'm not fond of the extra symbol - it's not obvious what it means and it all starts to get a little Perl-esque, where your cat walking across your keyboard can generate a valid program.


May 11, 2004
A. Stevenson wrote:
> That said, I'm not fond of the extra symbol - it's not obvious what it means and it all starts to get a little Perl-esque, where your cat walking across your keyboard can generate a valid program.

Well - Perl certainly is one of the ugliest languages out there, but in string handling, there certainly are few languages to beat it. If we want to get powerful strings, it would be ignorant to refuse being influence from Perl in certain -- well-considered -- respects.
May 11, 2004
In article <c7q7mo$2vh8$2@digitaldaemon.com>, Norbert Nemec says...
>
>A. Stevenson wrote:
>> That said, I'm not fond of the extra symbol - it's not obvious what it means and it all starts to get a little Perl-esque, where your cat walking across your keyboard can generate a valid program.
>
>Well - Perl certainly is one of the ugliest languages out there, but in string handling, there certainly are few languages to beat it. If we want to get powerful strings, it would be ignorant to refuse being influence from Perl in certain -- well-considered -- respects.

True enough - I use both Perl and C in my work to achieve different tasks - they're good for different things.

But still I find Perl difficult and painful to use. Whenever I have to do something big in Perl I find myself relieved to go back to C!

One of the things that I find most difficult in Perl (other than regex stuff) is the various internal variables ($_, $!, $1 etc) where the symbol itself gives no clue to what it is to the uninformed layman like myself. Shortcuts that are useful to Perl hackers of a lot of experience cause me a headache:

example:

while ( <SPAM> )
{
chomp;
dosomething($_);
}

It's fairly obvious to anyone with Perl experience what this is shorthand for, but it caused me a minor headache.

Anyway, my point is that shortcuts for the experienced ought to be obvious enough that the inexperienced can understand them without having to ask silly questions or find an obscure reference in a document.

Of course, the above is only my opinion and does not necessarily represent truth, beauty or freedom for all.


May 11, 2004
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c7p67p$1ejh$1@digitaldaemon.com...
> Phill wrote:
>
> >Im not with you, you can already do this:
> >
> > test[0..test.length - 10];
> >
> >
> People have been requesting a $ symbol to be used as length.  I believe it would be better to have a more generic idea that  uses words instead of ugly symbols.
>
I agree with you, I would much rather the word length.
There is no "now what did '$' mean again?"
Plus I think that most people are already used to
the word length and what it means.

> test[0..length - 10];
>
> Is shorter and quite readable.  It's like doing:
>
> with (test) { test[0..length-10]; }
>

Ok I get the picture now.
This could be very handy.

I just love "with", its really fantastic, and (OT)also foreach.

Thanks
         Phill


May 11, 2004
A. Stevenson wrote:

>In article <c7p18a$17t5$1@digitaldaemon.com>, J C Calvarese says...
>  
>
>>J Anderson wrote:
>>    
>>
>>>Just a thought with slices.  What about if the namespaces became optional inside the square brackets (ie like a with statement).
>>>
>>>ie
>>>= test[0..length];
>>>      
>>>
>>That's a clever idea, but I'm afraid it'd lead to subtle errors. What if you meant test2.length? You won't get a compile error. If you're lucky, you'd get a runtime error. If you're unlucky, you'd just get the wrong result (and might not even realize it's the wrong result).
>>
>>But using a symbol to represent this idea would be vastly "safer":
>> = test[0..$length];
>>or
>> = test[0..$];
>>
>>My 2 cents.
>>
>>    
>>
>>>instead of:
>>>= test[0..test.length];
>>>
>>>Then you could also do negative versions like:
>>>
>>>= test[0..length-10];
>>>
>>>Since we use length in slices all the time, this would be handy syntax sugar.
>>>
>>>This would also apply to UDT's.
>>>
>>>      
>>>
>>-- 
>>Justin (a/k/a jcc7)
>>http://jcc_7.tripod.com/d/
>>    
>>
>
>Or an even more subtle source of confusion.
>Suppose I have the following (contrived example):
>
>int[] bob( int[] spam )
>{
>int length = 20;
>return spam[6..length]
>}
>
>Which 'length' would be referred to? How would I specify the function-scope
>variable length instead of the array property length? 
>
>If you want to use 207 class functions/members in array indices, why not wrap it
>in a with block?
>
>That said, I'm not fond of the extra symbol - it's not obvious what it means and
>it all starts to get a little Perl-esque, where your cat walking across your
>keyboard can generate a valid program.
>
>
>  
>
What JC mentioned could be an issue.  This case would not be an issue, as the compile could easily cause a collision error.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 11, 2004
A. Stevenson wrote:

> One of the things that I find most difficult in Perl (other than regex stuff) is the various internal variables ($_, $!, $1 etc) where the symbol itself gives no clue to what it is to the uninformed layman like myself. Shortcuts that are useful to Perl hackers of a lot of experience cause me a headache:

I fully agree there. I never used much of Perl, but make and bash have that same situation. Anyhow, the situation with operators in D seems different to me: operators have very different semantics and meanings. Whether you introduce a keyword or an operator for a given purpose, you'll always have to know what it means or look up the reference for it.

For example: I find the keyword "is" even more confusing than "===" because a newby believes to know intuitively what it means, so he might not take the time to look it up and then misinterpret it.

And for the rule of implicit namespaces within indexing expression: the efford it takes to explain to someone what the details of this mechanism are huge compared to the three lines it takes to explain the proposed "$".

May 11, 2004
"A. Stevenson" <A._member@pathlink.com> wrote in message news:c7q6nh$2ufr$1@digitaldaemon.com...
> In article <c7p18a$17t5$1@digitaldaemon.com>, J C Calvarese says...
> >
> >J Anderson wrote:
> >> Just a thought with slices.  What about if the namespaces became optional inside the square brackets (ie like a with statement).
> >>
> >> ie
> >> = test[0..length];
> >
> >That's a clever idea, but I'm afraid it'd lead to subtle errors. What if you meant test2.length? You won't get a compile error. If you're lucky, you'd get a runtime error. If you're unlucky, you'd just get the wrong result (and might not even realize it's the wrong result).
> >
> >But using a symbol to represent this idea would be vastly "safer":
> >  = test[0..$length];
> >or
> >  = test[0..$];
> >
> >My 2 cents.
> >
> >>
> >> instead of:
> >> = test[0..test.length];
> >>
> >> Then you could also do negative versions like:
> >>
> >> = test[0..length-10];
> >>
> >> Since we use length in slices all the time, this would be handy syntax sugar.
> >>
> >> This would also apply to UDT's.
> >>
> >
> >
> >--
> >Justin (a/k/a jcc7)
> >http://jcc_7.tripod.com/d/
>
> Or an even more subtle source of confusion.
> Suppose I have the following (contrived example):
>
> int[] bob( int[] spam )
> {
> int length = 20;
> return spam[6..length]
> }
>
> Which 'length' would be referred to? How would I specify the
function-scope
> variable length instead of the array property length?

Well according to  JA's  suggestion, the length being
referred to would be the length of the spam[].
I dont know about anyone else, but I know that
I would have changed the name of the int to save
future confusion.

With JA's suggestion there would be no need for
using a with block, because the [] would automatically
act like a with block for anything that is inside the
[].

Phill.



May 11, 2004
In article <c7qbon$4ba$1@digitaldaemon.com>, Phill says...
>
>
>"A. Stevenson" <A._member@pathlink.com> wrote in message news:c7q6nh$2ufr$1@digitaldaemon.com...
>> In article <c7p18a$17t5$1@digitaldaemon.com>, J C Calvarese says...
>> >
>> >J Anderson wrote:
>> >> Just a thought with slices.  What about if the namespaces became optional inside the square brackets (ie like a with statement).
>> >>
>> >> ie
>> >> = test[0..length];
>> >
>> >That's a clever idea, but I'm afraid it'd lead to subtle errors. What if you meant test2.length? You won't get a compile error. If you're lucky, you'd get a runtime error. If you're unlucky, you'd just get the wrong result (and might not even realize it's the wrong result).
>> >
>> >But using a symbol to represent this idea would be vastly "safer":
>> >  = test[0..$length];
>> >or
>> >  = test[0..$];
>> >
>> >My 2 cents.
>> >
>> >>
>> >> instead of:
>> >> = test[0..test.length];
>> >>
>> >> Then you could also do negative versions like:
>> >>
>> >> = test[0..length-10];
>> >>
>> >> Since we use length in slices all the time, this would be handy syntax sugar.
>> >>
>> >> This would also apply to UDT's.
>> >>
>> >
>> >
>> >--
>> >Justin (a/k/a jcc7)
>> >http://jcc_7.tripod.com/d/
>>
>> Or an even more subtle source of confusion.
>> Suppose I have the following (contrived example):
>>
>> int[] bob( int[] spam )
>> {
>> int length = 20;
>> return spam[6..length]
>> }
>>
>> Which 'length' would be referred to? How would I specify the
>function-scope
>> variable length instead of the array property length?
>
>Well according to  JA's  suggestion, the length being
>referred to would be the length of the spam[].
>I dont know about anyone else, but I know that
>I would have changed the name of the int to save
>future confusion.
>
>With JA's suggestion there would be no need for
>using a with block, because the [] would automatically
>act like a with block for anything that is inside the
>[].
>
>Phill.
>
>
>

But suppose that the array is a class that overloads opSlice - you get problems if your local variables have the name of any of the public class methods/member vars/attributes