www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Instead of $ Length...

reply "Charlie Patterson" <charliep1 excite.com> writes:
... how about nothing?

a = b[3..];

For a kind of consistency:

a = [0..3] or
a = [..3];
Mar 10 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"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.
Mar 10 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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
Mar 10 2005
parent Derek Parnell <derek psych.ward> writes:
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
Mar 11 2005
prev sibling next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
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
Mar 10 2005
parent Derek Parnell <derek psych.ward> writes:
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
Mar 11 2005
prev sibling next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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.
Most of the time (not always, but most of the time), when we're slicing relative to the end of the array, we're slicing to the very end. Do we really require to have a shortcut for slicing short of that? It seems to me that we could, quite reasonably, require that for the unusual case (slicing short of the end) they have to use the full, written out version. So I would argue that maybe it's time to resurrect the b[3..] syntax. Frankly, I liked b[3..length], and I'm not sure that it's something that we have to change. But if we're going to change it, then let's do something that reads easily for a newbie, and not some PERL-esque nightmare like $.
Mar 11 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 11 Mar 2005 10:54:56 -0700, Russ Lewis 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.
Most of the time (not always, but most of the time), when we're slicing relative to the end of the array, we're slicing to the very end. Do we really require to have a shortcut for slicing short of that? It seems to me that we could, quite reasonably, require that for the unusual case (slicing short of the end) they have to use the full, written out version. So I would argue that maybe it's time to resurrect the b[3..] syntax. Frankly, I liked b[3..length], and I'm not sure that it's something that we have to change. But if we're going to change it, then let's do something that reads easily for a newbie, and not some PERL-esque nightmare like $.
It would seem I'm a lucky person as I've never used, nor even read, anything in PERL. A non-alpha symbol such as '$' doesn't frighten me nor give me any concern. It seems I'm become accustomed to such beasties such as + * - ! & |, so $ isn't such a biggie for me to cope with. On the other hand, no one is forcing me to use $ either. <humor attempt=on> May be we should also introduce alternate syntax so we have the option to remove other naked non-alpha tokens from our code? add varA to varB giving varC end-statement instead of varC = varB + varB; </humor> -- Derek Parnell Melbourne, Australia 12/03/2005 8:04:08 AM
Mar 11 2005
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Derek Parnell wrote:
 It would seem I'm a lucky person as I've never used, nor even read,
 anything in PERL. A non-alpha symbol such as '$' doesn't frighten me nor
 give me any concern. It seems I'm become accustomed to such beasties such
 as + * - ! & |, so $ isn't such a biggie for me to cope with.
 
 On the other hand, no one is forcing me to use $ either.
 
 <humor attempt=on>
 May be we should also introduce alternate syntax so we have the option to
 remove other naked non-alpha tokens from our code?
 
    add varA to varB giving varC end-statement
 
 instead of 
 
    varC = varB + varB;
 
 </humor>
I am not in the least opposed to using non-alpha tokens in code. They make the code shorter, and thus, often, easy to read. However, some tokens that we use are trivial for a newbie to read because they have history in algebra or other sciences; thus, the code is easy to read from the start. Others, like ~ or %, the newbie just has to learn by rote. I argue that the language should resist using these types of tokens - use them, yes, but use them only for a really important need. My reference to PERL was not a criticism of using non-alpha tokens; it was, instead, intended as a criticsim of using arbitrary syntaxes to give syntax sugar. For every such proposal, propoents can argue that "hey, it's only one more thing to write, and it will make my code MUCH easier," but after you've done it a few times, the language becomes an unintelligible nightmare of esoteric gibberish. Few PERL programmers know all of the odd shortcuts, so each programmer can write some sort of "cool" program that will confuse most other programmers. There must be a compelling case for every syntax sugar. IMHO, there isn't one for $.
Mar 11 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:

 <humor attempt=on>
 May be we should also introduce alternate syntax so we have the option to
 remove other naked non-alpha tokens from our code?
 
    add varA to varB giving varC end-statement
 
 instead of 
 
    varC = varB + varB;
 
 </humor>
It's actually a good thing, trying to protect Freedom of Programming... Like http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css-auth.babel-eng.txt But better done by tools, of course. --anders PS. http://www.nosoftwarepatents.com/
Mar 11 2005
next sibling parent pragma <pragma_member pathlink.com> writes:
In article <d0t5g1$jvn$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
It's actually a good thing, trying to protect Freedom of Programming...

Like http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css-auth.babel-eng.txt
My God, its full of words! - EricAnderton at yahoo
Mar 11 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 11 Mar 2005 23:18:41 +0100, Anders F Björklund wrote:

 Derek Parnell wrote:
 
 <humor attempt=on>
 May be we should also introduce alternate syntax so we have the option to
 remove other naked non-alpha tokens from our code?
 
    add varA to varB giving varC end-statement
 
 instead of 
 
    varC = varB + varB;
 
 </humor>
It's actually a good thing, trying to protect Freedom of Programming... Like http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css-auth.babel-eng.txt But better done by tools, of course.
Oh that was just beautiful. That is going on the office wall for sure! -- Derek Parnell Melbourne, Australia 12/03/2005 4:21:43 PM
Mar 11 2005
parent Kris <Kris_member pathlink.com> writes:
In article <nivnsmu7c3h8$.scp3dzyhlp43.dlg 40tude.net>, Derek Parnell says...
On Fri, 11 Mar 2005 23:18:41 +0100, Anders F Björklund wrote:

 Derek Parnell wrote:
 
 <humor attempt=on>
 May be we should also introduce alternate syntax so we have the option to
 remove other naked non-alpha tokens from our code?
 
    add varA to varB giving varC end-statement
 
 instead of 
 
    varC = varB + varB;
 
 </humor>
It's actually a good thing, trying to protect Freedom of Programming... Like http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css-auth.babel-eng.txt But better done by tools, of course.
Oh that was just beautiful. That is going on the office wall for sure!
I have a friend who would occasionally (late at night, and well into a rowdy party) grab a page or two of my C-listings and read it aloud, slowly, as if it were poetry. With gratuitous pause for effect before the inevitable "... semicolon ... carriage-return" People would join in, like a chorus, on the latter. Especially those who had a drink in both hands :~) Then we'd throw him into the pool.
Mar 11 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"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?
This was suggested but I can't find the posts about it.
It's hard to search for nothing <g>.
 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.
It starts causing a lot of parsing problems when the expressions become non-trivial.
Mar 11 2005
prev sibling next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
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];

 
Mar 10 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
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
Mar 10 2005
parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Mar 10 2005
parent John Reimer <brk_6502 yahoo.com> writes:
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
Mar 10 2005