Digital Mars - digitalmars.D - The new "$" has an inconsistent behavior

↑ ↓ ← → David L. Davis <SpottedTiger yahoo.com> writes:

The "$" appears to have an inconsistent behavior as seen in the test program
below, and it really should be nailed down before anyone uses it in their D
programs�once of course, it's approved that it will be used to stand for
array.length when it's between the array brackets ([ $ ]). So, should "$" stand
for "length - 1" or "length?" Myself I'd like for it to stand for "length - 1,"
because it saves me some extra typing by removing the need for "- 1." 

Tho I still think using the "$" for this is still a waste of a good symbol which
could be put to better use on something else. If it's approved by the group,
then I will use it a lot!! :)

# // test2.d
# private import std.stdio;
# 
# int main()
# {
#     char[] sTest = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
#
#     // Here "$" does "length - 1"
#     writefln( "\"" ~ sTest[ 0 .. $ ] ~ "\"" ); 
#    
#     // Here "$" does "length - 1," not "length - 2"
#     writefln( "\"", sTest[ $ - 1 ], "\"" ); 
#    
#     // Here "$" won't compile as is, and gets the following errors:
#     // test2.d(8): incompatible types for (("\"") ~ (cast(int)(sTest[cast
#                    (int)(__dollar - 1)]))): 'char[]' and 'int'
#     // test2.d(8): Can only concatenate arrays, not (char[] ~ int)
#     // test2.d(8): incompatible types for (("\"" ~ cast(int)(sTest[cast(int)
#                    (__dollar - 1)])) ~ ("\"")): 'int' and 'char[]'
#     // test2.d(8): Can only concatenate arrays, not (int ~ char[])
#     // test2.d(9): incompatible types for (("\"") ~ (cast(int)(sTest[cast
#                    (int)(__dollar)]))): 'char[]' and 'int'
#     // test2.d(9): Can only concatenate arrays, not (char[] ~ int)
#     // test2.d(9): incompatible types for (("\"" ~ cast(int)(sTest[cast(int)
#                    (__dollar)])) ~ ("\"")): 'int' and 'char[]'
#     // test2.d(9): Can only concatenate arrays, not (int ~ char[])    
#     //writefln( "\"" ~ sTest[ $ - 1 ] ~ "\"" ); 
#
#     // Here it compiles both, but "$" gives:
#     // Error: ArrayBoundsError test2(24)
#     //writefln( "\"", sTest[ $ ], "\"" );  
#     
#     // Error: ArrayBoundsError test2(24)
#     //writefln( sTest[ $ ] );
#     
#     // "$" compiles, and gives "Z", the same as "length - 1"
#     writefln( "\"", sTest[ $ - 1 ], "\"" ); 
#     
#     return 0;
# }

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Mar 09 2005

↑ ↓ ← → pragma <pragma_member pathlink.com> writes:

In article <d0niiq$31d5$1 digitaldaemon.com>, David Medlock says...
<snip>

I think the $ is a bad choice.

What does a dollar sign have to do with length of an array?
We use '.' and [] because C/C++ uses them.
What is the precedence for '$'?
It lowers readability and doesn't add much at all to the language.


I think the use of '$' can be traced back to regular expressions, where it
represents 'end of line'.  It means almost the same thing in this context ('end
of string/array'), so I wouldn't think it a bad token to use per-se.

It *does* take some getting used to though.

- EricAnderton at yahoo

Mar 09 2005

↑ ↓ ← → David Medlock <amedlock nospam.org> writes:

pragma wrote:
 In article <d0niiq$31d5$1 digitaldaemon.com>, David Medlock says...
 
<snip>

I think the $ is a bad choice.

What does a dollar sign have to do with length of an array?
We use '.' and [] because C/C++ uses them.
What is the precedence for '$'?
It lowers readability and doesn't add much at all to the language.


 
 I think the use of '$' can be traced back to regular expressions, where it
 represents 'end of line'.  It means almost the same thing in this context ('end
 of string/array'), so I wouldn't think it a bad token to use per-se.
 
 It *does* take some getting used to though.
 
 - EricAnderton at yahoo



I hear you, however using regular expressions( which are neither regular 
nor (readably)expressive ) as a basis for new syntax is still up for 
debate...

Perl 6 is tossing the old regex inconsistencies.
Regexes are meant to be space conscious at the cost of readability, 
whereas code really shouldn't be.

It should be as readable as possible, since maintenance is something 
like 70+%(?) of the cost of software.

In doing my DManager stuff, I looked through some old Delphi code to 
brush up and I was amazed at how readable it is.  I am not saying Walter 
should emulate Pascal, but its readability a worthy attribute.

Another $0.02 from
-David

Mar 09 2005

↑ ↓ ← → Kris <Kris_member pathlink.com> writes:

In article <d0nmoa$4kf$1 digitaldaemon.com>, Jarrett Billingsley says...
 I think the use of '$' can be traced back to regular expressions,


Of course, to someone who has no idea what regex syntax even is, it just 
seems stupid.  Especially coming from a BASIC background, in which $ is the 
"string variable" suffix.

 It *does* take some getting used to though.


I really hate how length has been deprecated.  I really don't like the $ one 
bit. 


Hold onto your shorts, Jarrett! Walter is apparently trying to make the
development process more transparent, and this is one way in which (it was
suggested) to make this happen. We should support him in doing this, rather than
miscontrue it.

If you look at the changelog, it effectively describes this as a "test". It's
good that Walter get's feedback on your preferences, but nothing has been
deprecated at this time :-)

Having said that, I'd have to agree with you. Let's hope that general opinion
converges on some means of collecting the various 'meta-tags' into a
recognizable form, whilst still being reasonably explicit?

While also agreeing with what Ben noted (regarding the vague PP association), I
think it would be good to see  length,  argptr,  arguments, and so on (or
$length, $argptr, $arguments). Firstly; there's no chance of a user-name clash,
since those symbols are not valid in user-identifiers. Second; it open the door
to further meta-tags without having to worry about additional reserved words.
Third; in a nod to Ben, they /are/ easily identifiable from the rest of the
source. This could be viewed as a really good thing, rather than a negative.

As Matthew pointed out, there's perhaps some subtle 'overloading' going on when
one applies the same notion to  file,  line,  timestamp etc (or $file, $line,
$timestamp), since these latter meta-tags are kinda' static whereas the former
items are not. I'm not convinced that's really a problem though ~ don't we
kinda' use apply conventions to static and non-static members of a class? 

Regardless, it would behoove D to support point one and two above.

- Kris

Mar 09 2005

↑ ↓ ← → Kris <Kris_member pathlink.com> writes:

In article <d0npv9$8ia$1 digitaldaemon.com>, Kris says...
As Matthew pointed out, there's perhaps some subtle 'overloading' going on when
one applies the same notion to  file,  line,  timestamp etc (or $file, $line,
$timestamp), since these latter meta-tags are kinda' static whereas the former
items are not. I'm not convinced that's really a problem though ~ don't we
kinda' use apply conventions to static and non-static members of a class? 


Ack! Wish we could edit posts on this NG;

That last question should have read "don't we kinda' apply similar conventions
to static and non-static class members?"

Mar 09 2005

↑ ↓ ← → =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Jarrett Billingsley wrote:

 I really hate how length has been deprecated. 
 I really don't like the $ one bit. 


It's just the "magic" length variable that
has (presumably ?) been deprecated now...

And nobody will miss the disappearance of that one.
http://www.digitalmars.com/d/changelog.html#new099


the .length array property still works, and
probably still will when the others are gone... :-)

See http://www.digitalmars.com/d/arrays.html:

  Within the [ ] of a static or a dynamic array,
 the variable length  is implicitly declared and
 set to the length of the array.

 	int[4] foo;
 	int[]  bar = foo;


 // These expressions are equivalent:
 	bar[]
 	bar[0 .. 4]


   	bar[0 .. length]
  	bar[0 .. $]

 	bar[0 .. bar.length]


--anders

Mar 09 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:d0nmoa$4kf$1 digitaldaemon.com...
 I think the use of '$' can be traced back to regular expressions,


 Of course, to someone who has no idea what regex syntax even is, it 
 just seems stupid.


That may be so, but that's a piss poor rationale for a criticism. Were 
it as black and white as that, then ignorance of regex would be the 
thing to address. It's not exactly a useless skill to have ...

  Especially coming from a BASIC background, in which $ is the "string 
 variable" suffix.

 It *does* take some getting used to though.


 I really hate how length has been deprecated.  I really don't like the 
 $ one bit.


Ok, that's opinion. Gotcha. Now, how about some substantiation?

(btw, I'm now moving away from $ after having been a great supporter. 
And feeling a little guilty that my former enthusiasm may have helped 
influence Walter to go down this cul-de-sac <g>)

Mar 09 2005

↑ ↓ ← → "Walter" <newshound digitalmars.com> writes:

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0nup9$ei4$1 digitaldaemon.com...
 (btw, I'm now moving away from $ after having been a great supporter.
 And feeling a little guilty that my former enthusiasm may have helped
 influence Walter to go down this cul-de-sac <g>)


No worries, I deliberately put it in on a trial basis. It appears to be a
sinking ship, though. I wouldn't be sorry to see it go.

BTW, there's a subtlety here that has been largely overlooked. Suppose one
creates a class that overloads [] and wants to look like an array? What's $
then? For length, it was simple. The 'this' pointer for the class reference
is added to the scope on the opening [, and removed on the closing ]. Then,
if the class declares a 'length' property, that length will be found and
used.

Of course, I can bash the compiler to make $ look up a classes' length
property, too, but that just strikes me as uuugly.

Maybe we're just going at this all wrong. I really like length as the
implicitly declared array length, for the reason it is straightforward and
it just looks visually appealing in use. Having it be __length is ugly, and
$length isn't much better. Both of the latter would also require the
this.length lookup hack.

Maybe the right answer is to just make it illegal to declare a local
variable with the name 'length'. Fields, functions, etc., could still be
named 'length'. It's still a bit of a hack, but language design is rarely
free of that stuff.

Mar 09 2005

↑ ↓ ← → David Medlock <amedlock nospam.com> writes:

Walter wrote:

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0nup9$ei4$1 digitaldaemon.com...
 
(btw, I'm now moving away from $ after having been a great supporter.
And feeling a little guilty that my former enthusiasm may have helped
influence Walter to go down this cul-de-sac <g>)


 
 No worries, I deliberately put it in on a trial basis. It appears to be a
 sinking ship, though. I wouldn't be sorry to see it go.
 
 BTW, there's a subtlety here that has been largely overlooked. Suppose one
 creates a class that overloads [] and wants to look like an array? What's $
 then? For length, it was simple. The 'this' pointer for the class reference
 is added to the scope on the opening [, and removed on the closing ]. Then,
 if the class declares a 'length' property, that length will be found and
 used.
 
 Of course, I can bash the compiler to make $ look up a classes' length
 property, too, but that just strikes me as uuugly.
 
 Maybe we're just going at this all wrong. I really like length as the
 implicitly declared array length, for the reason it is straightforward and
 it just looks visually appealing in use. Having it be __length is ugly, and
 $length isn't much better. Both of the latter would also require the
 this.length lookup hack.
 
 Maybe the right answer is to just make it illegal to declare a local
 variable with the name 'length'. Fields, functions, etc., could still be
 named 'length'. It's still a bit of a hack, but language design is rarely
 free of that stuff.
 
 


syntax, Walter?

with( a ) x[] = a[0..length-1];

I suppose it could lead to some weird things like:

int[] a = new int[100];
int[] x;
with(a) x = dup;

but it would still be pretty clean and not require new syntax.

Mar 09 2005

↑ ↓ ← → pragma <pragma_member pathlink.com> writes:

In article <d0o5s1$l7o$2 digitaldaemon.com>, David Medlock says...
Walter wrote:
 Maybe the right answer is to just make it illegal to declare a local
 variable with the name 'length'. Fields, functions, etc., could still be
 named 'length'. It's still a bit of a hack, but language design is rarely
 free of that stuff.
 
 


syntax, Walter?

with( a ) x[] = a[0..length-1];

I suppose it could lead to some weird things like:

int[] a = new int[100];
int[] x;
with(a) x = dup;

but it would still be pretty clean and not require new syntax.


::sound of hand smacking on own forehead::

It's so simple.  I feel downright foolish for backing the '$' solution at this
point.  

From the docs: "The with statement is a way to simplify repeated references to
the same object."

I tried it for fun, and dmd 0.116 does indeed kick back an error complaining
that 'a' isn't an object.  Seems to me this is broken anyway since with() would
make just as much sense with anything with 'properties' attached to it (which
covers the entirely language really).

int i;
with(i) writefln("maxint is: %d",max); // useless but this *should* be valid 

Not only will it fix all this array '$' business, but it'll make things more
consistent.

- EricAnderton at yahoo

Mar 09 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message 
news:d0o4ji$k7k$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0nup9$ei4$1 digitaldaemon.com...
 (btw, I'm now moving away from $ after having been a great supporter.
 And feeling a little guilty that my former enthusiasm may have helped
 influence Walter to go down this cul-de-sac <g>)


 No worries, I deliberately put it in on a trial basis. It appears to 
 be a
 sinking ship, though. I wouldn't be sorry to see it go.

 BTW, there's a subtlety here that has been largely overlooked. Suppose 
 one
 creates a class that overloads [] and wants to look like an array? 
 What's $
 then? For length, it was simple. The 'this' pointer for the class 
 reference
 is added to the scope on the opening [, and removed on the closing ]. 
 Then,
 if the class declares a 'length' property, that length will be found 
 and
 used.

 Of course, I can bash the compiler to make $ look up a classes' length
 property, too, but that just strikes me as uuugly.

 Maybe we're just going at this all wrong. I really like length as the
 implicitly declared array length, for the reason it is straightforward 
 and
 it just looks visually appealing in use. Having it be __length is 
 ugly, and
 $length isn't much better. Both of the latter would also require the
 this.length lookup hack.


I'm not convinced that $length is bad, and that's partly because I 
_like_ the idea of it doing property lookups. I don't see any real 
difference between an array having a length property and a Vector having 
a length property or a std.openrj.Record having a length property.

But this brings us onto a much broader debate about properties, and my 
desire to make properties much less implicit than they are, and that's a 
huge 'nother debate that can wait. (I'm saving 'em up, so as I can be 
mean to you constantly for the next 3 months <g>.)

May I suggest that the way forward is to remove _all_ shortcuts for 
length, and just require people to do the non-too-taxing-if-we're-honest 
business of prefixing .length with the thing it's the length of?

Then, from that more basic standpoint we can take a little time to 
identity how much of a problem really exists.

(After all, we don't want to end up like Perl, do we? It amuses me a 
little to note that of all the "I like feature X from language Y" that 
we all occasionally do, no-one ever sets Y=Perl. <g>)

 Maybe the right answer is to just make it illegal to declare a local
 variable with the name 'length'. Fields, functions, etc., could still 
 be
 named 'length'. It's still a bit of a hack, but language design is 
 rarely
 free of that stuff.


No. I strongly disagree with this. It's either a keyword (and therefore 
reserved from identifiers) or it's not. Otherwise, we're in .HACK land.

Mar 09 2005

↑ ↓ ← → Benji Smith <dlanguage xxagg.com> writes:

On Wed, 9 Mar 2005 16:27:00 -0800, "Walter"
<newshound digitalmars.com> wrote:

Maybe the right answer is to just make it illegal to declare a local
variable with the name 'length'. Fields, functions, etc., could still be
named 'length'. It's still a bit of a hack, but language design is rarely
free of that stuff.


Personally, I think the best way would be to make it illegal to use
the length property without the name of the array/object to which it
belongs. For example...

   // illegal, unless "length" has been declared as a variable
   int[] slice = full[x .. length];

...would be illegal, and would be replaced by...

   int[] slice = full[x .. full.length];

...or, in cases where the array has been poorly_named_to_begin_with,
you could do something like this...

   int len = idioticly_long_variable_name.length;
   int[] slice = idioticly_long_variable_name[x .. len];

It's slightly less syntactically-sugary than using "length" without a
prefix, or using a "$" token, but the headaches avoided by doing so
would be worth it, in my opinion.

--Benji Smith

Mar 09 2005

↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:

On Wed, 09 Mar 2005 19:19:48 -0700, Benji Smith <dlanguage xxagg.com>  
wrote:
 ...or, in cases where the array has been poorly_named_to_begin_with,
 you could do something like this...

    int len = idioticly_long_variable_name.length;
    int[] slice = idioticly_long_variable_name[x .. len];

 It's slightly less syntactically-sugary than using "length" without a
 prefix, or using a "$" token, but the headaches avoided by doing so
 would be worth it, in my opinion.


Just remember 'len' could, in certain situations, become stale before use.  
Not in the above example, but in slightly more complex code, eg.

int len = array.length;
if (foo(array)) {             <- foo modifies array.length
   writef("%s"array[5..len]);  <- len is actually > or < than array.length  
here
}

Regan

Mar 13 2005

↑ ↓ ← → =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Regan Heath wrote:

    int len = idioticly_long_variable_name.length;
    int[] slice = idioticly_long_variable_name[x .. len];




 Just remember 'len' could, in certain situations, become stale before 
 use.  Not in the above example, but in slightly more complex code, eg.
 
 int len = array.length;
 if (foo(array)) {             <- foo modifies array.length
   writef("%s"array[5..len]);  <- len is actually > or < than 
 array.length  here
 }


But *only* if array is declared with an "out" parameter...
(and those are "dangerous" even with int and char and so ?)

 import std.stdio;
 
 void foo(char[] str)
 {
   str ~= "X";
 }
 
 void bar(inout char[] str)
 {
   str ~= "X";
 }
 
 void main()
 {
   char[] str = "test";
   writefln("str: %s", str);
 
   foo(str);
   writefln("foo: %s", str);
 
   bar(str);
   writefln("bar: %s", str);
 }


str: test
foo: test
bar: testX

Note how changing the slice declared as "in" did *not* do anything.
(except if you modify the actual characters, another discussion...)

--anders

Mar 13 2005

↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:

On Sun, 13 Mar 2005 10:42:26 +0100, Anders F Bj�rklund <afb algonet.se>  
wrote:
 Regan Heath wrote:

    int len = idioticly_long_variable_name.length;
    int[] slice = idioticly_long_variable_name[x .. len];




 Just remember 'len' could, in certain situations, become stale before  
 use.  Not in the above example, but in slightly more complex code, eg.
  int len = array.length;
 if (foo(array)) {             <- foo modifies array.length
   writef("%s"array[5..len]);  <- len is actually > or < than  
 array.length  here
 }


 But *only* if array is declared with an "out" parameter...
 (and those are "dangerous" even with int and char and so ?)


True. Thanks.

Regan

Mar 13 2005

↑ ↓ ← → xs0 <xs0 xs0.com> writes:

 BTW, there's a subtlety here that has been largely overlooked. Suppose one
 creates a class that overloads [] and wants to look like an array? What's $
 then? For length, it was simple. The 'this' pointer for the class reference
 is added to the scope on the opening [, and removed on the closing ]. Then,
 if the class declares a 'length' property, that length will be found and
 used.
 
 Of course, I can bash the compiler to make $ look up a classes' length
 property, too, but that just strikes me as uuugly.


Well, I agree that $ with classes is odd, but $length to me isn't. It's 
like a reserved word and can be defined as "the .length of whatever the 
enclosing [] refers to".


 Maybe we're just going at this all wrong. I really like length as the
 implicitly declared array length, for the reason it is straightforward and
 it just looks visually appealing in use. Having it be __length is ugly, and
 $length isn't much better. Both of the latter would also require the
 this.length lookup hack.


Well, I'd say that $length is better than length, because it behaves 
differently than any other identifier (afaik, length is the only one 
with special treatment), so it should also look unlike other 
identifiers.. Same goes for _arguments vs. $args -- it is special in 
that it refers to the "..." and is not explicitly declared anywhere, so 
it should also look special. IMHO, of course..


 Maybe the right answer is to just make it illegal to declare a local
 variable with the name 'length'. Fields, functions, etc., could still be
 named 'length'. It's still a bit of a hack, but language design is rarely
 free of that stuff.


To me that's just too inconsistent - for all other possible identifiers, 
you can either use them everywhere or nowhere (if reserved). Having 
length be special is just odd, even more so, because I guess it would be 
forbidden as a local var even in functions that don't even use [length]. 
I can just see the hundreds of posts this would produce :)


xs0

Mar 09 2005

↑ ↓ ← → "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

 That may be so, but that's a piss poor rationale for a criticism. Were it 
 as black and white as that, then ignorance of regex would be the thing to 
 address. It's not exactly a useless skill to have ...


To tell the truth, I've never even seen regular expressions before I came 
across D, and I haven't exactly lived under a rock.  It seems like anyone 
who uses a Posix-based OS has knowledge of them, and I'm not sure why, as 
I've personally never used Linux or the like.

 Ok, that's opinion. Gotcha. Now, how about some substantiation?


Sorry, I have nothing to prove.

Mar 09 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:d0odfv$sor$1 digitaldaemon.com...
 That may be so, but that's a piss poor rationale for a criticism. 
 Were it as black and white as that, then ignorance of regex would be 
 the thing to address. It's not exactly a useless skill to have ...


 To tell the truth, I've never even seen regular expressions before I 
 came across D, and I haven't exactly lived under a rock.  It seems 
 like anyone who uses a Posix-based OS has knowledge of them, and I'm 
 not sure why, as I've personally never used Linux or the like.

 Ok, that's opinion. Gotcha. Now, how about some substantiation?


 Sorry, I have nothing to prove.


Don't be so childish. It's not a question of having something to prove, 
or at least not in the way you mean.

If you want people to diligently read your posts when they contain 
unsubstantiated opinion, you're living in a dream world. Any people who 
are interested in such  are *far* more likely to watch Fox News.

Mar 09 2005

↑ ↓ ← → David Medlock <amedlock nospam.org> writes:

Matthew wrote:
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:d0odfv$sor$1 digitaldaemon.com...
 
That may be so, but that's a piss poor rationale for a criticism. 
Were it as black and white as that, then ignorance of regex would be 
the thing to address. It's not exactly a useless skill to have ...


To tell the truth, I've never even seen regular expressions before I 
came across D, and I haven't exactly lived under a rock.  It seems 
like anyone who uses a Posix-based OS has knowledge of them, and I'm 
not sure why, as I've personally never used Linux or the like.


Ok, that's opinion. Gotcha. Now, how about some substantiation?


Sorry, I have nothing to prove.


 
 Don't be so childish. It's not a question of having something to prove, 
 or at least not in the way you mean.
 
 If you want people to diligently read your posts when they contain 
 unsubstantiated opinion, you're living in a dream world. Any people who 
 are interested in such  are *far* more likely to watch Fox News.
 
 
 


Fox _News_ and Fox.  Fox News is quite good, as reflected in its current 
ratings surge.  The rest of the media is 'Rather' biased, imo.

Mar 10 2005

↑ ↓ ← → "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

 Don't be so childish. It's not a question of having something to prove, or 
 at least not in the way you mean.


The point I was tryint to make is that it seems like there are people here 
who are constantly trying to trip others up on the most minor of logical 
errors, and to put it bluntly, it's stupid.  Sorry if I expressed an opinion 
without anything to back it up, I wasn't aware that it was such a dire 
mistake on my part.  I thought Walter was testing this $ out, and would 
rather have peoples' opinions about it rather than constant bickering about 
whose logic is faulty.

 If you want people to diligently read your posts when they contain 
 unsubstantiated opinion, you're living in a dream world. Any people who 
 are interested in such  are *far* more likely to watch Fox News.


Oh good, throw in some opinionated blanket political statements.  You're a 
real charmer.

Mar 10 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

 If you want people to diligently read your posts when they contain 
 unsubstantiated opinion, you're living in a dream world. Any people 
 who are interested in such  are *far* more likely to watch Fox News.


 Oh good, throw in some opinionated blanket political statements. 
 You're a real charmer.


Yes. Dropping in that was not sensible, given the insane level of 
political sensibility in the world at the moment. (Nor does it 
necessarily reflect any political persuasion I might hold.) Consider it 
sheepishly retracted.

Mar 10 2005

↑ ↓ ← → "Derek Parnell" <derek psyc.ward> writes:

On Thu, 10 Mar 2005 07:37:51 +1100, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 I think the use of '$' can be traced back to regular expressions,


 Of course, to someone who has no idea what regex syntax even is, it just
 seems stupid.  Especially coming from a BASIC background, in which $ is  
 the
 "string variable" suffix.

 It *does* take some getting used to though.


 I really hate how length has been deprecated.  I really don't like the  
 $ one
 bit.


I love the $. It's like coming home again. It reads well because it is  
something I'm used to and comfortable with using. It seems natural to me.



-- 
Derek

Mar 10 2005

↑ ↓ ← → "Ben Hinkle" <bhinkle mathworks.com> writes:

"David Medlock" <amedlock nospam.org> wrote in message 
news:d0niiq$31d5$1 digitaldaemon.com...
 <snip>

 I think the $ is a bad choice.

 What does a dollar sign have to do with length of an array?
 We use '.' and [] because C/C++ uses them.
 What is the precedence for '$'?
 It lowers readability and doesn't add much at all to the language.

 This similar to some choices made durings C++'s lifetime(C too! see 
 trigraphs) which makes for cluttered code, lots of special syntaxes to 
 rememeber, and general inconsistency.  Not this one decision, but add them 
 all up and you get a mess.

 All my opinion, of course.
 -David


I agree. Using an identifier is something people recognize and can 
understand. Seeing $ will confuse people and think there is more magic in 
there than there is.  When I see $ used for this (or even when I imagine 
$length, $arguments, etc) I can't relate it to any other C-like language 
construct that I know. It actually looks to me like a preprocessor hook of 
some kind or shell-like environment variable expansion.

Mar 09 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d0nlai$302$1 digitaldaemon.com...
 "David Medlock" <amedlock nospam.org> wrote in message 
 news:d0niiq$31d5$1 digitaldaemon.com...
 <snip>

 I think the $ is a bad choice.

 What does a dollar sign have to do with length of an array?
 We use '.' and [] because C/C++ uses them.
 What is the precedence for '$'?
 It lowers readability and doesn't add much at all to the language.

 This similar to some choices made durings C++'s lifetime(C too! see 
 trigraphs) which makes for cluttered code, lots of special syntaxes 
 to rememeber, and general inconsistency.  Not this one decision, but 
 add them all up and you get a mess.

 All my opinion, of course.
 -David


 I agree. Using an identifier is something people recognize and can 
 understand. Seeing $ will confuse people and think there is more magic 
 in there than there is.  When I see $ used for this (or even when I 
 imagine $length, $arguments, etc) I can't relate it to any other 
 C-like language construct that I know.


Hmm. That actually gets a big "So what?". I mean, seeing char[], aa 
declaration syntax, opThis and opThat, are all foreign/unfamiliar.

To me it seems not the slightest bizarre. But then I am a big fan of 
Ruby, which has such things by the bucketload.

 It actually looks to me like a preprocessor hook of some kind or 
 shell-like environment variable expansion.


Is that a bad thing? I think the opposite. If we adopt this $xyz thing - 
i.e. we can find significant use, and it can have good unambiguous 
semantics - then the distinctness of it is precisely what's required.

Mar 09 2005

↑ ↓ ← → David Medlock <amedlock nospam.com> writes:

Matthew wrote:
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message 
 news:d0nlai$302$1 digitaldaemon.com...
 
"David Medlock" <amedlock nospam.org> wrote in message 
news:d0niiq$31d5$1 digitaldaemon.com...

<snip>

I think the $ is a bad choice.

What does a dollar sign have to do with length of an array?
We use '.' and [] because C/C++ uses them.
What is the precedence for '$'?
It lowers readability and doesn't add much at all to the language.

This similar to some choices made durings C++'s lifetime(C too! see 
trigraphs) which makes for cluttered code, lots of special syntaxes 
to rememeber, and general inconsistency.  Not this one decision, but 
add them all up and you get a mess.

All my opinion, of course.
-David


I agree. Using an identifier is something people recognize and can 
understand. Seeing $ will confuse people and think there is more magic 
in there than there is.  When I see $ used for this (or even when I 
imagine $length, $arguments, etc) I can't relate it to any other 
C-like language construct that I know.


 
 Hmm. That actually gets a big "So what?". I mean, seeing char[], aa 
 declaration syntax, opThis and opThat, are all foreign/unfamiliar.
 
 To me it seems not the slightest bizarre. But then I am a big fan of 
 Ruby, which has such things by the bucketload.
 


Well I am a big fan of python, so lets use the array[:] syntax.  Just 
because its used somewhere doesn't mean its good here.

D is derived from C and C++, so idioms from those languages make LOTS of 
sense, since that is whom you are targeting with the language.

OpThis and opThat are worlds better than the C++ way, more readable and 
easier for tools to parse.

Not trying to start an argument here, but no one has really made the 
'why its better' or even 'why its needed' argument.

...

Programming languages should be designed not by piling feature on top of 
feature, but by removing the weaknesses and restrictions that make 
additional features appear necessary.
(from Revised Report on Scheme, 1991)

Mar 09 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

 To me it seems not the slightest bizarre. But then I am a big fan of 
 Ruby, which has such things by the bucketload.


 Well I am a big fan of python, so lets use the array[:] syntax.  Just 
 because its used somewhere doesn't mean its good here.

 D is derived from C and C++, so idioms from those languages make LOTS 
 of sense, since that is whom you are targeting with the language.

 OpThis and opThat are worlds better than the C++ way, more readable 
 and easier for tools to parse.

 Not trying to start an argument here, but no one has really made the 
 'why its better' or even 'why its needed' argument.

 ...

 Programming languages should be designed not by piling feature on top 
 of feature, but by removing the weaknesses and restrictions that make 
 additional features appear necessary.
 (from Revised Report on Scheme, 1991)


reaching to the converted

Mar 09 2005

↑ ↓ ← → David Medlock <amedlock nospam.com> writes:

Matthew wrote:
To me it seems not the slightest bizarre. But then I am a big fan of 
Ruby, which has such things by the bucketload.


Well I am a big fan of python, so lets use the array[:] syntax.  Just 
because its used somewhere doesn't mean its good here.

D is derived from C and C++, so idioms from those languages make LOTS 
of sense, since that is whom you are targeting with the language.

OpThis and opThat are worlds better than the C++ way, more readable 
and easier for tools to parse.

Not trying to start an argument here, but no one has really made the 
'why its better' or even 'why its needed' argument.

...

Programming languages should be designed not by piling feature on top 
of feature, but by removing the weaknesses and restrictions that make 
additional features appear necessary.
(from Revised Report on Scheme, 1991)


 
 reaching to the converted
 


Matthew. :)

Mar 09 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"David Medlock" <amedlock nospam.com> wrote in message 
news:d0o426$jnd$1 digitaldaemon.com...
 Matthew wrote:
To me it seems not the slightest bizarre. But then I am a big fan of 
Ruby, which has such things by the bucketload.


Well I am a big fan of python, so lets use the array[:] syntax.  Just 
because its used somewhere doesn't mean its good here.

D is derived from C and C++, so idioms from those languages make LOTS 
of sense, since that is whom you are targeting with the language.

OpThis and opThat are worlds better than the C++ way, more readable 
and easier for tools to parse.

Not trying to start an argument here, but no one has really made the 
'why its better' or even 'why its needed' argument.

...

Programming languages should be designed not by piling feature on top 
of feature, but by removing the weaknesses and restrictions that make 
additional features appear necessary.
(from Revised Report on Scheme, 1991)



 reaching to the converted


 mentioned Matthew. :)


and now you've lost me completely.

You seem to be saying that familiarity with some languages is fine and 
with others it's not. That may be so, but drawing the line is always 
going to be an arbitrary decision. Have I missed anything beyond that?

Mar 09 2005

↑ ↓ ← → David Medlock <amedlock nospam.com> writes:

Matthew wrote:

 
 
 and now you've lost me completely.
 
 You seem to be saying that familiarity with some languages is fine and 
 with others it's not. That may be so, but drawing the line is always 
 going to be an arbitrary decision. Have I missed anything beyond that?
 


All I am saying is that C-isms are probably a lot more familiar to D 
users than Python-isms, Perlisms, et al.  There is no $ operator that 
I'm familiar with in C, so I think it is a bad choice.

Would the syntax be useful to some? Sure it would. And it would be 
totally confusing to anyone trying to learn the language and shrug off 
the C++ syntactical complexities.

-David

Mar 09 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"David Medlock" <amedlock nospam.com> wrote in message 
news:d0o5mk$l7o$1 digitaldaemon.com...
 Matthew wrote:

 and now you've lost me completely.

 You seem to be saying that familiarity with some languages is fine 
 and with others it's not. That may be so, but drawing the line is 
 always going to be an arbitrary decision. Have I missed anything 
 beyond that?


 All I am saying is that C-isms are probably a lot more familiar to D 
 users than Python-isms, Perlisms, et al.  There is no $ operator that 
 I'm familiar with in C, so I think it is a bad choice.

 Would the syntax be useful to some? Sure it would. And it would be 
 totally confusing to anyone trying to learn the language and shrug off 
 the C++ syntactical complexities.


Ok, well that is what I thought you meant. But I think it's a fatuous 
point because (i) syntactic familiarity can be a double-edged sword, and 
(ii) there's plenty in D to confuse a C-language oldie who's new to D.

And now I think we're entering the pointless territory, so I'll shut up. 
Feel free to have the last word ... :-)

Mar 09 2005

↑ ↓ ← → "John C" <johnch_atms hotmail.com> writes:

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d0nv4f$ett$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message 
 news:d0nlai$302$1 digitaldaemon.com...
 "David Medlock" <amedlock nospam.org> wrote in message 
 news:d0niiq$31d5$1 digitaldaemon.com...
 <snip>

 I think the $ is a bad choice.

 What does a dollar sign have to do with length of an array?
 We use '.' and [] because C/C++ uses them.
 What is the precedence for '$'?
 It lowers readability and doesn't add much at all to the language.

 This similar to some choices made durings C++'s lifetime(C too! see 
 trigraphs) which makes for cluttered code, lots of special syntaxes to 
 rememeber, and general inconsistency.  Not this one decision, but add 
 them all up and you get a mess.

 All my opinion, of course.
 -David


 I agree. Using an identifier is something people recognize and can 
 understand. Seeing $ will confuse people and think there is more magic in 
 there than there is.  When I see $ used for this (or even when I imagine 
 $length, $arguments, etc) I can't relate it to any other C-like language 
 construct that I know.


 Hmm. That actually gets a big "So what?". I mean, seeing char[], aa 
 declaration syntax, opThis and opThat, are all foreign/unfamiliar.

 To me it seems not the slightest bizarre. But then I am a big fan of Ruby, 
 which has such things by the bucketload.

 It actually looks to me like a preprocessor hook of some kind or 
 shell-like environment variable expansion.


 Is that a bad thing? I think the opposite. If we adopt this $xyz thing - 
 i.e. we can find significant use, and it can have good unambiguous 
 semantics - then the distinctness of it is precisely what's required.


When initializing a static array, the : (colon) is used to refer to a 
specific index. Perhaps this could be adapted to refer to the length when 
inside the brackets. It wouldn't look too foreign.

    items[0 .. :length]
    items[:length - 1]

and so on.

It's also reminicent of the C++ scope operator (::) - whether that's a good 
thing or bad I'll not comment on.

Mar 09 2005

↑ ↓ ← → Ben Hinkle <Ben_member pathlink.com> writes:

Catching up on "old" threads... could be irrelevant by now.

 I agree. Using an identifier is something people recognize and can 
 understand. Seeing $ will confuse people and think there is more magic 
 in there than there is.  When I see $ used for this (or even when I 
 imagine $length, $arguments, etc) I can't relate it to any other 
 C-like language construct that I know.


Hmm. That actually gets a big "So what?". I mean, seeing char[], aa 
declaration syntax, opThis and opThat, are all foreign/unfamiliar.


The syntax is based on very familiar C constructs and people can guess the
semantics of what is going on. Using $ in expressions gives no clue about
semantics. I agree $length would be better than $ but why invent a wacky syntax
that will cause C programmer to think D has left Kansas and landed in Oz? I'd
prefer to reserve "wacky" syntax for advanced concepts (like the !() for
template instantiation and such) and let bread-and-butter D code look like
bread-and-butter C/Java/C++ code.

To me it seems not the slightest bizarre. But then I am a big fan of 
Ruby, which has such things by the bucketload.


that's fine. To me it reminds me of shell scripting variable expansion. To some
it means Basic strings.

 It actually looks to me like a preprocessor hook of some kind or 
 shell-like environment variable expansion.


Is that a bad thing? I think the opposite. If we adopt this $xyz thing - 
i.e. we can find significant use, and it can have good unambiguous 
semantics - then the distinctness of it is precisely what's required.


True - though I suppose it boils down to what is considered significant. I think
there was a post about waiting on this whole thing until more uses can be found
(or something like that).

Mar 09 2005

↑ ↓ ← → "Lionello Lunesu" <lio lunesu.removethis.com> writes:

 #     // Here "$" does "length - 1"
 #     writefln( "\"" ~ sTest[ 0 .. $ ] ~ "\"" );


I think that's just the way the slicing operator works: from 0 'up to but 
not including' length. It's the same if you write it out using 'the old 
syntax': array[0..length] will get you elements [0] till [length-1].

http://www.digitalmars.com/d/arrays.html#slicing

 #     // Here "$" does "length - 1," not "length - 2"
 #     writefln( "\"", sTest[ $ - 1 ], "\"" );


I haven't tested it, but if it were 'length' it should have printed the last 
element in the array?

L.

Mar 09 2005

↑ ↓ ← → "Derek Parnell" <derek psyc.ward> writes:

On Thu, 10 Mar 2005 05:56:21 +1100, David L. Davis  
<SpottedTiger yahoo.com> wrote:

 The "$" appears to have an inconsistent behavior as seen in the test  
 program
 below, and it really should be nailed down before anyone uses it in  
 their D
 programs…once of course, it's approved that it will be used to stand for
 array.length when it's between the array brackets ([ $ ]). So, should  
 "$" stand
 for "length - 1" or "length?" Myself I'd like for it to stand for  
 "length - 1,"
 because it saves me some extra typing by removing the need for "- 1."


Ummm...no it is working exactly as if you had have typed "sTest.length"  
instead of "$".

You have to remember the weird way that slice references work. Namely that  
a slice of [X .. Y] selects all the elements from X up to but not  
including Y. And that references are zero-based. Thus array[array.length]  
always references the non-existant element just after the last one. And  
array[0 .. array.length] references element 0 through to, but not  
including, the non-existant one just beyond the end.

Weird I know, but Walter has chosen.


-- 
Derek

Mar 09 2005

↑ ↓ ← → Kris <Kris_member pathlink.com> writes:

In article <op.sndzksf7nxgd8b umalgas>, Derek Parnell says...
On Thu, 10 Mar 2005 05:56:21 +1100, David L. Davis  
<SpottedTiger yahoo.com> wrote:

 The "$" appears to have an inconsistent behavior as seen in the test  
 program
 below, and it really should be nailed down before anyone uses it in  
 their D
 programs…once of course, it's approved that it will be used to stand for
 array.length when it's between the array brackets ([ $ ]). So, should  
 "$" stand
 for "length - 1" or "length?" Myself I'd like for it to stand for  
 "length - 1,"
 because it saves me some extra typing by removing the need for "- 1."


Ummm...no it is working exactly as if you had have typed "sTest.length"  
instead of "$".

You have to remember the weird way that slice references work. Namely that  
a slice of [X .. Y] selects all the elements from X up to but not  
including Y. And that references are zero-based. Thus array[array.length]  
always references the non-existant element just after the last one. And  
array[0 .. array.length] references element 0 through to, but not  
including, the non-existant one just beyond the end.

Weird I know, but Walter has chosen.



FWIW; what Walter has done is a compromise over what is sometimes called
"end-point paranoia" ~ most often witnessed in graphics libs, but relevant here
also (google that phrase to find some QuickDraw links).

When writing the Mango HTTP server, I don't recall one time where I had to
compensate for such things; and there's a whole lot of slicing going on in there
:-)

I know it seems a bit wacky that part of slicing is 'n' and another part is
'n-1', but I've found it to work well in practice.

Mar 09 2005

↑ ↓ ← → "Derek Parnell" <derek psyc.ward> writes:

On Thu, 10 Mar 2005 07:33:46 +1100, Kris <Kris_member pathlink.com> wrote:

[snip]

 Weird I know, but Walter has chosen.



 FWIW; what Walter has done is a compromise over what is sometimes called
 "end-point paranoia" ~ most often witnessed in graphics libs, but  
 relevant here
 also (google that phrase to find some QuickDraw links).

 When writing the Mango HTTP server, I don't recall one time where I had  
 to
 compensate for such things; and there's a whole lot of slicing going on  
 in there
 :-)

 I know it seems a bit wacky that part of slicing is 'n' and another part  
 is
 'n-1', but I've found it to work well in practice.


I realize that Walter's choice has been done for very good and sound  
reasons, mainly I think to do with performance. It's just that I'm also  
used to working with Euphoria and that uses a 1-based indexing scheme.  
That is the first item is 1, the second item is 2, etc... and the last  
item is $. Slices in Euphoria are inclusive.  array[$] is the last item.  
array[1..$] is the first item to the last item inclusively.

No big deal.
-- 
Derek




-- 
Derek

Mar 09 2005

↑ ↓ ← → Dave <Dave_member pathlink.com> writes:

In article <op.sndzksf7nxgd8b umalgas>, Derek Parnell says...
On Thu, 10 Mar 2005 05:56:21 +1100, David L. Davis  
<SpottedTiger yahoo.com> wrote:

 The "$" appears to have an inconsistent behavior as seen in the test  
 program
 below, and it really should be nailed down before anyone uses it in  
 their D
 programs…once of course, it's approved that it will be used to stand for
 array.length when it's between the array brackets ([ $ ]). So, should  
 "$" stand
 for "length - 1" or "length?" Myself I'd like for it to stand for  
 "length - 1,"
 because it saves me some extra typing by removing the need for "- 1."


Ummm...no it is working exactly as if you had have typed "sTest.length"  
instead of "$".

You have to remember the weird way that slice references work. Namely that  
a slice of [X .. Y] selects all the elements from X up to but not  
including Y. And that references are zero-based. Thus array[array.length]  
always references the non-existant element just after the last one. And  
array[0 .. array.length] references element 0 through to, but not  
including, the non-existant one just beyond the end.

Weird I know, but Walter has chosen.


It works that way to be consistent with 0 based array elements. Otherwise, you'd
be having to do things like this all the time:

arr[X .. arr.length - 1]; /* or */ arr[X .. $ - 1] /* etc.. */

I just think of it as for(int i = X; i < Y; i++) { /*...*/ }

-- 
Derek

Mar 09 2005

↑ ↓ ← → David L. Davis <SpottedTiger yahoo.com> writes:

In article <op.sndzksf7nxgd8b umalgas>, Derek Parnell says...
Ummm...no it is working exactly as if you had have typed "sTest.length"  
instead of "$".

You have to remember the weird way that slice references work. Namely that  
a slice of [X .. Y] selects all the elements from X up to but not  
including Y. And that references are zero-based. Thus array[array.length]  
always references the non-existant element just after the last one. And  
array[0 .. array.length] references element 0 through to, but not  
including, the non-existant one just beyond the end.

Weird I know, but Walter has chosen.


-- 
Derek


Opps! Thanks for the reminder, I've been using slices for almost a year now.
Guess I got a brain-freeze when looking at the funny syntax "$" instead of the
normal array.length. :) 

It's funny the things one accepts as fact after you've used them for a while,
until their appearance changes...like changing array[ 0 .. length ] to array[ 0
. $ ]. Now I'm feeling a little embrassed.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Mar 09 2005

↑ ↓ ← → Stewart Gordon <smjg_1998 yahoo.com> writes:

David L. Davis wrote:
 The "$" appears to have an inconsistent behavior as seen in the test program
 below, and it really should be nailed down before anyone uses it in their D
 programs�once of course, it's approved that it will be used to stand for
 array.length when it's between the array brackets ([ $ ]). So, should "$" stand
 for "length - 1" or "length?" Myself I'd like for it to stand for "length - 1,"
 because it saves me some extra typing by removing the need for "- 1." 


Redefining it this way means that you'd have to use

     array[2..$+1]

to slice from element 2 to the end of an array.  Seems somewhat sillier 
than using $-1 to refer to the final element'll ever look.  And as for 
the fencepost errors....

 Tho I still think using the "$" for this is still a waste of a good symbol
which
 could be put to better use on something else. If it's approved by the group,
 then I will use it a lot!! :)
 
 # // test2.d
 # private import std.stdio;
 # 
 # int main()
 # {
 #     char[] sTest = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 #
 #     // Here "$" does "length - 1"
 #     writefln( "\"" ~ sTest[ 0 .. $ ] ~ "\"" ); 



So the output is

"ABCDEFGHIJKLMNOPQRSTUVWXY"

?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.

Mar 10 2005

↑ ↓ ← → David L. Davis <SpottedTiger yahoo.com> writes:

In article <d0pggr$238v$1 digitaldaemon.com>, Stewart Gordon says...
David L. Davis wrote:
 The "$" appears to have an inconsistent behavior as seen in the test program
 below, and it really should be nailed down before anyone uses it in their D
 programs�once of course, it's approved that it will be used to stand for
 array.length when it's between the array brackets ([ $ ]). So, should "$" stand
 for "length - 1" or "length?" Myself I'd like for it to stand for "length - 1,"
 because it saves me some extra typing by removing the need for "- 1." 


Redefining it this way means that you'd have to use

     array[2..$+1]

to slice from element 2 to the end of an array.  Seems somewhat sillier 
than using $-1 to refer to the final element'll ever look.  And as for 
the fencepost errors....

 Tho I still think using the "$" for this is still a waste of a good symbol
which
 could be put to better use on something else. If it's approved by the group,
 then I will use it a lot!! :)
 
 # // test2.d
 # private import std.stdio;
 # 
 # int main()
 # {
 #     char[] sTest = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 #
 #     // Here "$" does "length - 1"
 #     writefln( "\"" ~ sTest[ 0 .. $ ] ~ "\"" ); 



So the output is

"ABCDEFGHIJKLMNOPQRSTUVWXY"

?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.


Stewart I don't which version you're using, but I'm using the Windows version of
dmd v0.116, and below is the results I get...which seems to be different from
your test.

# // test2b.d
# private import std.stdio;
# 
# int main()
# {
#     char[] sTest = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
#
#     // Here $ does .length - 1
#     writefln( "\"" ~ sTest[ 0 .. $ ] ~ "\"" ); 
#     writefln( "\"" ~ sTest[ 0 .. sTest.length ] ~ "\"" );
#
#     return 0;
# }

Output:
C:\dmd>bin\dmd test2b.d
C:\dmd\bin\..\..\dm\bin\link.exe test2b,,,user32+kernel32/noi;

C:\dmd>test2b
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"

C:\dmd>

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Mar 10 2005

↑ ↓ ← → Stewart Gordon <smjg_1998 yahoo.com> writes:

David L. Davis wrote:
<snip>
 Stewart I don't which version you're using, but I'm using the Windows version
of
 dmd v0.116, and below is the results I get...which seems to be different from
 your test.


What test?  I was merely restating what you were telling me it does.

 # // test2b.d
 # private import std.stdio;
 # 
 # int main()
 # {
 #     char[] sTest = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 #
 #     // Here $ does .length - 1
 #     writefln( "\"" ~ sTest[ 0 .. $ ] ~ "\"" ); 
 #     writefln( "\"" ~ sTest[ 0 .. sTest.length ] ~ "\"" );
 #
 #     return 0;
 # }
 
 Output:
 C:\dmd>bin\dmd test2b.d
 C:\dmd\bin\..\..\dm\bin\link.exe test2b,,,user32+kernel32/noi;
 
 C:\dmd>test2b
 "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
 "ABCDEFGHIJKLMNOPQRSTUVWXYZ"


That is correct behaviour.  And your comment just above the writefln 
statements is inconsistent with it.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.

Mar 10 2005

↑ ↓ ← → David L. Davis <SpottedTiger yahoo.com> writes:

In article <d0potn$2c1c$1 digitaldaemon.com>, Stewart Gordon says...
David L. Davis wrote:
<snip>
 Stewart I don't which version you're using, but I'm using the Windows 
 version of dmd v0.116, and below is the results I get...which seems to be 
 different from your test.


What test?  I was merely restating what you were telling me it does.

 # // test2b.d
 # private import std.stdio;
 # 
 # int main()
 # {
 #     char[] sTest = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 #
 #     // Here $ does .length - 1
 #     writefln( "\"" ~ sTest[ 0 .. $ ] ~ "\"" ); 
 #     writefln( "\"" ~ sTest[ 0 .. sTest.length ] ~ "\"" );
 #
 #     return 0;
 # }
 
 Output:
 C:\dmd>bin\dmd test2b.d
 C:\dmd\bin\..\..\dm\bin\link.exe test2b,,,user32+kernel32/noi;
 
 C:\dmd>test2b
 "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
 "ABCDEFGHIJKLMNOPQRSTUVWXYZ"


That is correct behaviour.  And your comment just above the writefln 
statements is inconsistent with it.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.


Ok. I see where you�re coming from now. In that comment above the first
writefln() I was pointing out that [0 .. $] and [0 .. $ - 1] are giving the
exact same results, which is, it displays the whole string (array of characters)
value. So with that in mind, the statement above the writefln() was not
inconsistent with the results, but in appearance they look very inconsistent. 

Please do not be offended if you already know the following.  But someone here
on the forum pointed out to me, that this is the way D deals with the length
when it�s doing array slicing. In other words sTest.length equals 26 which is
based on 1 starting in the first position. Where as slicing [0..sTest.length] is
based on zero starting in the first position, thus in this special case with a
little D magic (hack)� both �sTest.length� and �sTest.length � 1� end up
displaying same result. 

Anyway, thanks for your comments.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Mar 10 2005

↑ ↓ ← → Stewart Gordon <smjg_1998 yahoo.com> writes:

David L. Davis wrote:
<snip>
 Please do not be offended if you already know the following.  But someone here
 on the forum pointed out to me, that this is the way D deals with the length
 when it�s doing array slicing. In other words sTest.length equals 26 which is
 based on 1 starting in the first position.


Length is length.  Is has nothing whatsoever to do with how elements are 
numbered.

Suppose you have a row of items numbered like this

0 1 2 3 4 5 6 7 8 9

There are ten of them.  Now suppose they're numbered like this

1 2 3 4 5 6 7 8 9 10

There are still ten of them.  Now suppose they're numbered

3 4 5 6 7 8 9 10 11 12

Here, there are ten again.  The length of an array is defined as the 
number of elements in the array.  Not by the index of the last element 
by any interpretation.

 Where as slicing [0..sTest.length] is
 based on zero starting in the first position, thus in this special case with a
 little D magic (hack)� both �sTest.length� and �sTest.length � 1� end up
 displaying same result. 


I'll have to try it and see when I get home.  If it does as you 
describe, then it's a bug in DMD.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.

Mar 10 2005

↑ ↓ ← → MicroWizard <MicroWizard_member pathlink.com> writes:

Thanks Stewart, your words restored my faith in the world.
(I almost started to write a very long explanation about
counting simple thing)

D uses 0 based array indexing. There are no sign to have any bugs in that.
Anybody could complain about the fact, that the indexing IS 0 based,
but not about, how could it be done. It's elementary mathematics.

Length is length.  Is has nothing whatsoever to do with how elements are 
numbered.


Question (for $1000):
If there are 5 tram stations and you want to travel along the whole line,
how many times will the tram start or how many stations will you pass?

4, no question. This is how our human languages are "accurate".
Programming languages can not be so imperfect.
(Remember the array indexbase problems in Visual Basic: Ubound, Lbound, etc.)

That's all.

Tamas Nagy

 little D magic (hack)� both �sTest.length� and �sTest.length � 1� end up
 displaying same result. 




I'll have to try it and see when I get home.  If it does as you 
describe, then it's a bug in DMD.


You don't need. I did it.

import std.stdio;

void main(char[][] args)
{
char[] tiz="0123456789";
char[] husz="01234567890123456789";

printf("tiz=%.*s\n",tiz);
printf("tiz[]=%.*s\n",tiz[]);
printf("tiz[0..tiz.length=%.*s\n",tiz[0..tiz.length]);
printf("tiz[0..$]=%.*s\n",tiz[0..$]);
printf("tiz[0..10]=%.*s\n",tiz[0..10]);
printf("tiz[3..tiz.length-3]=%.*s\n",tiz[3..tiz.length-3]);
printf("tiz[3..$-3]=%.*s\n",tiz[3..$-3]);
printf("tiz[3..7]=%.*s\n",tiz[3..7]);
printf("\n");
printf("tiz[0..9]=%.*s\n",tiz[0..9]);
printf("tiz[0..$-1]=%.*s\n",tiz[0..$-1]);
printf("\n");

printf("husz=%.*s\n",husz);
printf("husz[]=%.*s\n",husz[]);
printf("husz[0..husz.length]=%.*s\n",husz[0..husz.length]);
printf("husz[0..$]=%.*s\n",husz[0..$]);
printf("husz[0..20]=%.*s\n",husz[0..20]);
printf("husz[3..husz.length-3]=%.*s\n",husz[3..husz.length-3]);
printf("husz[3..$-3]=%.*s\n",husz[3..$-3]);
printf("husz[3..17]=%.*s\n",husz[3..17]);
printf("\n");
printf("husz[0..19]=%.*s\n",husz[0..19]);
printf("husz[0..$-1]=%.*s\n",husz[0..$-1]);
}

Result:
tiz=0123456789
tiz[]=0123456789
tiz[0..tiz.length=0123456789
tiz[0..$]=0123456789
tiz[0..10]=0123456789
tiz[3..tiz.length-3]=3456
tiz[3..$-3]=3456
tiz[3..7]=3456

tiz[0..9]=012345678
tiz[0..$-1]=012345678

husz=01234567890123456789
husz[]=01234567890123456789
husz[0..husz.length]=01234567890123456789
husz[0..$]=01234567890123456789
husz[0..20]=01234567890123456789
husz[3..husz.length-3]=34567890123456
husz[3..$-3]=34567890123456
husz[3..17]=34567890123456

husz[0..19]=0123456789012345678
husz[0..$-1]=0123456789012345678

Mar 10 2005

↑ ↓ ← → Shammah <Shammah_member pathlink.com> writes:

This whole argument stems from a weird array slicing interval.  It makes sense
once you play with it.  However, To begin with it's confusing.

In set builder notation an array slice is such:

array[ a .. b ];

Is there elements Array sub N where N is integers belonging to the interval [a,
b)

So it starts as a closed interval, and ends as an open one.  This is rather
counterintuitive, though useful.

One would expect it to be INCLUSIVE on both sides.


In article <d0qd17$n4$1 digitaldaemon.com>, MicroWizard says...
Thanks Stewart, your words restored my faith in the world.
(I almost started to write a very long explanation about
counting simple thing)

D uses 0 based array indexing. There are no sign to have any bugs in that.
Anybody could complain about the fact, that the indexing IS 0 based,
but not about, how could it be done. It's elementary mathematics.

Length is length.  Is has nothing whatsoever to do with how elements are 
numbered.


Question (for $1000):
If there are 5 tram stations and you want to travel along the whole line,
how many times will the tram start or how many stations will you pass?

4, no question. This is how our human languages are "accurate".
Programming languages can not be so imperfect.
(Remember the array indexbase problems in Visual Basic: Ubound, Lbound, etc.)

That's all.

Tamas Nagy

 little D magic (hack)� both �sTest.length� and �sTest.length � 1� end up
 displaying same result. 




I'll have to try it and see when I get home.  If it does as you 
describe, then it's a bug in DMD.


You don't need. I did it.

import std.stdio;

void main(char[][] args)
{
char[] tiz="0123456789";
char[] husz="01234567890123456789";

printf("tiz=%.*s\n",tiz);
printf("tiz[]=%.*s\n",tiz[]);
printf("tiz[0..tiz.length=%.*s\n",tiz[0..tiz.length]);
printf("tiz[0..$]=%.*s\n",tiz[0..$]);
printf("tiz[0..10]=%.*s\n",tiz[0..10]);
printf("tiz[3..tiz.length-3]=%.*s\n",tiz[3..tiz.length-3]);
printf("tiz[3..$-3]=%.*s\n",tiz[3..$-3]);
printf("tiz[3..7]=%.*s\n",tiz[3..7]);
printf("\n");
printf("tiz[0..9]=%.*s\n",tiz[0..9]);
printf("tiz[0..$-1]=%.*s\n",tiz[0..$-1]);
printf("\n");

printf("husz=%.*s\n",husz);
printf("husz[]=%.*s\n",husz[]);
printf("husz[0..husz.length]=%.*s\n",husz[0..husz.length]);
printf("husz[0..$]=%.*s\n",husz[0..$]);
printf("husz[0..20]=%.*s\n",husz[0..20]);
printf("husz[3..husz.length-3]=%.*s\n",husz[3..husz.length-3]);
printf("husz[3..$-3]=%.*s\n",husz[3..$-3]);
printf("husz[3..17]=%.*s\n",husz[3..17]);
printf("\n");
printf("husz[0..19]=%.*s\n",husz[0..19]);
printf("husz[0..$-1]=%.*s\n",husz[0..$-1]);
}

Result:
tiz=0123456789
tiz[]=0123456789
tiz[0..tiz.length=0123456789
tiz[0..$]=0123456789
tiz[0..10]=0123456789
tiz[3..tiz.length-3]=3456
tiz[3..$-3]=3456
tiz[3..7]=3456

tiz[0..9]=012345678
tiz[0..$-1]=012345678

husz=01234567890123456789
husz[]=01234567890123456789
husz[0..husz.length]=01234567890123456789
husz[0..$]=01234567890123456789
husz[0..20]=01234567890123456789
husz[3..husz.length-3]=34567890123456
husz[3..$-3]=34567890123456
husz[3..17]=34567890123456

husz[0..19]=0123456789012345678
husz[0..$-1]=0123456789012345678

Apr 10 2005