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