Thread overview | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 10, 2005 Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
... how about nothing? a = b[3..]; For a kind of consistency: a = [0..3] or a = [..3]; |
March 10, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charlie Patterson | "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com... > ... how about nothing? > > a = b[3..]; > > For a kind of consistency: > > a = [0..3] or > a = [..3]; This was suggested but I can't find the posts about it. The issue is that you want to use length/$/whatever in arbitrary expressions inside the brackets. Basically one wants a shortcut for writing array.length. The 'nothing proposal' isn't general enough. It might also have parsing issues but I can't really remember. |
March 10, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charlie Patterson | Yep, it is nice but what about this: a = b[ 0 .. b.length-1 ]; ? may be just: a = b[ 0 .. -1 ]? But this needs different interpretation of negative numbers in hi-index. "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com... > ... how about nothing? > > a = b[3..]; > > For a kind of consistency: > > a = [0..3] or > a = [..3]; > > |
March 10, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0qfbh$35p$1@digitaldaemon.com... > > "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com... >> ... how about nothing? >> >> a = b[3..]; >> >> For a kind of consistency: >> >> a = [0..3] or >> a = [..3]; > > This was suggested but I can't find the posts about it. The issue is that you want to use length/$/whatever in arbitrary expressions inside the brackets. Basically one wants a shortcut for writing array.length. The 'nothing proposal' isn't general enough. It might also have parsing issues but I can't really remember. IIRC I was one of the suggestors, based on Python experience with the nothing, and the argument against was precisely as you describe. I'd still favour it, because I think if one is doing anything more complex than a range from i to the end, the full ar.length version is the appropriate thing to use. Yours position-shifting-with-the-wind-ingly Matthew |
March 10, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charlie Patterson | Charlie Patterson wrote:
> ... how about nothing?
>
> a = b[3..];
>
> For a kind of consistency:
>
> a = [0..3] or
> a = [..3];
>
>
Yes, I also suggested it last round (a few hundred posts ago: see topic "$ instead of length"), but there wasn't too much discussion on it, other than how [..-1] and [..] would be interpreted (see Andrew's post also). Then the discussion phizzled out with no apparent interest. The suggestion seems to have been made by others independently in the past also, so it's not original (I was really hoping I had something original here :-) ). I like the idea of this, but I'm not sure if it holds up under deep analysis. If it does, we should go for it.
-JJR
|
March 10, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | Ben Hinkle wrote:
> "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com...
>
>>... how about nothing?
>>
>>a = b[3..];
>>
>>For a kind of consistency:
>>
>>a = [0..3] or
>>a = [..3];
>
>
> This was suggested but I can't find the posts about it. The issue is that you want to use length/$/whatever in arbitrary expressions inside the brackets. Basically one wants a shortcut for writing array.length. The 'nothing proposal' isn't general enough. It might also have parsing issues but I can't really remember.
>
>
The suggested solution to handle more generality was to allow negative numbers in the high index: [..-1] represents last_element - 1. But this might be more confusing than it's worth. Or we could just accept this as a new way for D.
-JJR
|
March 11, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | John Reimer wrote: > Charlie Patterson wrote: > >> ... how about nothing? >> >> a = b[3..]; >> >> For a kind of consistency: >> >> a = [0..3] or >> a = [..3]; >> >> > > Yes, I also suggested it last round (a few hundred posts ago: see topic "$ instead of length"), but there wasn't too much discussion on it, other than how [..-1] and [..] would be interpreted (see Andrew's post also). Then the discussion phizzled out with no apparent interest. The suggestion seems to have been made by others independently in the past also, so it's not original (I was really hoping I had something original here :-) ). I like the idea of this, but I'm not sure if it holds up under deep analysis. If it does, we should go for it. > > -JJR I think there was also some concern that an omitted start or stop may have been inadvertently omitted. It's kind of like the reason that D still requires ";" all over the place even though a missing semi-colon can usually be inferred from context. Requiring a little extra typing effort from the programmer every time can cut down on the ambiguities. I really like the underscore idea (_) in the another thread (http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/19096). It's a good balance between unobtrusive yet still requiring something. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/ |
March 11, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to J C Calvarese | J C Calvarese wrote:
> John Reimer wrote:
>
>> Charlie Patterson wrote:
>>
>>> ... how about nothing?
>>>
>>> a = b[3..];
>>>
>>> For a kind of consistency:
>>>
>>> a = [0..3] or
>>> a = [..3];
>>>
>>>
>>
>> Yes, I also suggested it last round (a few hundred posts ago: see topic "$ instead of length"), but there wasn't too much discussion on it, other than how [..-1] and [..] would be interpreted (see Andrew's post also). Then the discussion phizzled out with no apparent interest. The suggestion seems to have been made by others independently in the past also, so it's not original (I was really hoping I had something original here :-) ). I like the idea of this, but I'm not sure if it holds up under deep analysis. If it does, we should go for it.
>>
>> -JJR
>
>
> I think there was also some concern that an omitted start or stop may have been inadvertently omitted. It's kind of like the reason that D still requires ";" all over the place even though a missing semi-colon can usually be inferred from context. Requiring a little extra typing effort from the programmer every time can cut down on the ambiguities.
>
> I really like the underscore idea (_) in the another thread (http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/19096). It's a good balance between unobtrusive yet still requiring something.
>
Justin,
You make a valid point. But I still think that in this case omission is fairly obvious and the intention is clear (if the syntax is understood). Since the expression is confined to the brackets, the intention can be easily deduced. Furthermore, using this notation, I believe would catch the eye of a programmer more readily than not, flagging errors of omission more quickly (if there were indeed such an error).
I'm not quite sure when it's proper to make use of such omissions in language design. But, I guess in the long run, the community will decide.
-JJR
|
March 11, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | On Fri, 11 Mar 2005 09:25:33 +1100, Matthew wrote: > "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0qfbh$35p$1@digitaldaemon.com... >> >> "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com... >>> ... how about nothing? >>> >>> a = b[3..]; >>> >>> For a kind of consistency: >>> >>> a = [0..3] or >>> a = [..3]; >> >> This was suggested but I can't find the posts about it. The issue is that you want to use length/$/whatever in arbitrary expressions inside the brackets. Basically one wants a shortcut for writing array.length. The 'nothing proposal' isn't general enough. It might also have parsing issues but I can't really remember. > > IIRC I was one of the suggestors, based on Python experience with the nothing, and the argument against was precisely as you describe. > > I'd still favour it, because I think if one is doing anything more complex than a range from i to the end, the full ar.length version is the appropriate thing to use. > > Yours position-shifting-with-the-wind-ingly > > Matthew My view is that a = b[3..]; is ambiguous. Did the coder intend to slice to end of the array, or did they accidentally forget something? I cannot tell by just reading the code. However, a = b[3..$]; is not ambiguous. -- Derek Parnell Melbourne, Australia 11/03/2005 10:46:57 PM |
March 11, 2005 Re: Instead of $ Length... | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | On Thu, 10 Mar 2005 14:55:26 -0800, John Reimer wrote: > Ben Hinkle wrote: >> "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com... >> >>>... how about nothing? >>> >>>a = b[3..]; >>> >>>For a kind of consistency: >>> >>>a = [0..3] or >>>a = [..3]; >> >> >> This was suggested but I can't find the posts about it. The issue is that you want to use length/$/whatever in arbitrary expressions inside the brackets. Basically one wants a shortcut for writing array.length. The 'nothing proposal' isn't general enough. It might also have parsing issues but I can't really remember. >> >> > > The suggested solution to handle more generality was to allow negative numbers in the high index: [..-1] represents last_element - 1. But this might be more confusing than it's worth. Or we could just accept this as a new way for D. > > -JJR My view is that a = b[3..-1]; is ambiguous. Did the coder intend to slice to end of the array, or did they accidentally forget something? I cannot tell by just reading the code. However, a = b[3..$]; is not ambiguous. Also, we can get subtle bugs when using varaibles for slicing indexes. int x,y; GetExtents(x,y); XXX = YYY[x .. y]; But if there is a bug in GetExtents that cause negative values to be returned, we may find hard to track down the effect of the bug. Because instead of a run time error (array bounds) we not get a run time error that crashes the application, just some unexpected values appearing in a report or interface file or database? -- Derek Parnell Melbourne, Australia 11/03/2005 10:50:50 PM |
Copyright © 1999-2021 by the D Language Foundation