www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - yalp (yet another length proposal)

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
I don't know if this has been already proposed but I was pondering the 
"negative index" and the "missing index" proposals and it occurred to me 
that a place-holder that would be (a) an identifier, (b) unobtrusive and (c) 
unlikely to be used by a real coder is an underscore. I grepped phobos for 
some examples of a[a.length] and replaced them with a[_] to get a feel for 
how it would look. At one point Walter proposed making it an error to have 
the "magic length identifier" shadow a symbol with the same name - and I 
think that would catch any yahoo who actually wants to have symbols named _

./std/format.d: putstr(tmpbuf[n .. _]);
./std/math2.d: real result = coefficients[_ - 1];
./std/math2.d: if (s[_ - 1] == 'h')
./std/path.d:     return fullname[i .. _];
./std/path.d: return fullname[i .. _];
./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
./std/path.d: fullname = fullname[0 .. _ - existing.length] ~ ext;
./std/path.d:    return d.length < path.length && path[d.length] == sep[0];
./std/path.d:  else if (p1[_ - 1] == '\\')
./std/path.d:      p = p1 ~ p2[1 .. _];
./std/path.d:     else if (p1[_ - 1] == '\\')
./std/path.d: else if (p1[_ - 1] == sep[0])
./std/path.d:   if (fnmatch(name[j .. _], pattern[pi + 1 .. _]))
./std/regexp.d: result ~= string[p .. _];
[snip many more examples from phobos]
Mar 10 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
Aesthetically, I like this more than $ :).



"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d0q91g$2toq$1 digitaldaemon.com...

I don't know if this has been already proposed but I was pondering the 
"negative index" and the "missing index" proposals and it occurred to me 
that a place-holder that would be (a) an identifier, (b) unobtrusive and 
(c) unlikely to be used by a real coder is an underscore. I grepped phobos 
for some examples of a[a.length] and replaced them with a[_] to get a feel 
for how it would look. At one point Walter proposed making it an error to 
have the "magic length identifier" shadow a symbol with the same name - and 
I think that would catch any yahoo who actually wants to have symbols named 
_

 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];
 ./std/math2.d: if (s[_ - 1] == 'h')
 ./std/path.d:     return fullname[i .. _];
 ./std/path.d: return fullname[i .. _];
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: fullname = fullname[0 .. _ - existing.length] ~ ext;
 ./std/path.d:    return d.length < path.length && path[d.length] == 
 sep[0];
 ./std/path.d:  else if (p1[_ - 1] == '\\')
 ./std/path.d:      p = p1 ~ p2[1 .. _];
 ./std/path.d:     else if (p1[_ - 1] == '\\')
 ./std/path.d: else if (p1[_ - 1] == sep[0])
 ./std/path.d:   if (fnmatch(name[j .. _], pattern[pi + 1 .. _]))
 ./std/regexp.d: result ~= string[p .. _];
 [snip many more examples from phobos]
Mar 10 2005
prev sibling next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
My only qualm is that it's too hard to see.

But I'd be happy to give this a test, a la $, if _ became a reserved
identifier. (Shouldn't be too much of an imposition, since who's going
to want to use that anyway, other than Dobfuscators?)

(Don't you love this new try-it-and-see stuff? <g>)

The other advantage is that it saves $ for the future: TMP and all that 
..

"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d0q91g$2toq$1 digitaldaemon.com...

I don't know if this has been already proposed but I was pondering the
"negative index" and the "missing index" proposals and it occurred to
me that a place-holder that would be (a) an identifier, (b) unobtrusive
and (c) unlikely to be used by a real coder is an underscore. I grepped
phobos for some examples of a[a.length] and replaced them with a[_] to
get a feel for how it would look. At one point Walter proposed making
it an error to have the "magic length identifier" shadow a symbol with
the same name - and I think that would catch any yahoo who actually
wants to have symbols named _

 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];
 ./std/math2.d: if (s[_ - 1] == 'h')
 ./std/path.d:     return fullname[i .. _];
 ./std/path.d: return fullname[i .. _];
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: fullname = fullname[0 .. _ - existing.length] ~ ext;
 ./std/path.d:    return d.length < path.length && path[d.length] ==
 sep[0];
 ./std/path.d:  else if (p1[_ - 1] == '\\')
 ./std/path.d:      p = p1 ~ p2[1 .. _];
 ./std/path.d:     else if (p1[_ - 1] == '\\')
 ./std/path.d: else if (p1[_ - 1] == sep[0])
 ./std/path.d:   if (fnmatch(name[j .. _], pattern[pi + 1 .. _]))
 ./std/regexp.d: result ~= string[p .. _];
 [snip many more examples from phobos]
Mar 10 2005
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Ben Hinkle wrote:

 I don't know if this has been already proposed but I was pondering the 
 "negative index" and the "missing index" proposals and it occurred to me 
 that a place-holder that would be (a) an identifier, (b) unobtrusive and (c) 
 unlikely to be used by a real coder is an underscore. I grepped phobos for 
 some examples of a[a.length] and replaced them with a[_] to get a feel for 
 how it would look. At one point Walter proposed making it an error to have 
 the "magic length identifier" shadow a symbol with the same name - and I 
 think that would catch any yahoo who actually wants to have symbols named _
 
 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];


I like it. It's clever.

If someone wants to use _ as an actual identifier, they should be shot 
anyway (IMO). It should be used for something special.


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Mar 10 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 10 Mar 2005 23:03:58 -0600, J C Calvarese wrote:


 Ben Hinkle wrote:

 I don't know if this has been already proposed but I was pondering the 
 "negative index" and the "missing index" proposals and it occurred to me 
 that a place-holder that would be (a) an identifier, (b) unobtrusive and (c) 
 unlikely to be used by a real coder is an underscore. I grepped phobos for 
 some examples of a[a.length] and replaced them with a[_] to get a feel for 
 how it would look. At one point Walter proposed making it an error to have 
 the "magic length identifier" shadow a symbol with the same name - and I 
 think that would catch any yahoo who actually wants to have symbols named _
 
 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];


 
 I like it. It's clever.


It is significantly more difficult to see. Not every one has 20-y.o. eyes
any more? ;-)


 If someone wants to use _ as an actual identifier, they should be shot 
 anyway (IMO).


Yep, a pretty silly identifier name. But why? Because maybe its hard to
see?


 It should be used for something special.


What *is* this "something special" that I keep reading about?

-- 
Derek Parnell
Melbourne, Australia
11/03/2005 11:03:15 PM
Mar 11 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:onv6vwm3agbo$.1ezjtrb8uag1.dlg 40tude.net...

 On Thu, 10 Mar 2005 23:03:58 -0600, J C Calvarese wrote:


 Ben Hinkle wrote:

 I don't know if this has been already proposed but I was pondering the
 "negative index" and the "missing index" proposals and it occurred to me
 that a place-holder that would be (a) an identifier, (b) unobtrusive and 
 (c)
 unlikely to be used by a real coder is an underscore. I grepped phobos 
 for
 some examples of a[a.length] and replaced them with a[_] to get a feel 
 for
 how it would look. At one point Walter proposed making it an error to 
 have
 the "magic length identifier" shadow a symbol with the same name - and I
 think that would catch any yahoo who actually wants to have symbols 
 named _

 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];


 I like it. It's clever.


 It is significantly more difficult to see. Not every one has 20-y.o. eyes
 any more? ;-)


When surrounded by spaces it should be easier to pick out, but I agree 
visibility is the biggest drawback.


 If someone wants to use _ as an actual identifier, they should be shot
 anyway (IMO).


 Yep, a pretty silly identifier name. But why? Because maybe its hard to
 see?


More because it has no meaning. The only usage of _ as an identifier that I 
could find was a declaration in some C++ code in recls for an unused field 
of a struct. I didn't try to figure out the context too much but it looked 
like the struct was some OS struct with some padding in it. The only uses 
for _ that I can imagine outside of that is for code obfuscation contests.


 It should be used for something special.


 What *is* this "something special" that I keep reading about?


I was also pretty sceptical about the usefulness of $/length/whatever. Then 
I started grepping around to write a post about how silly the feature is and 
I realized it is more common than I thought. It seemed like about 1/3 to 1/2 
of indexing expressions would involve the length. So I started to think it 
would be useful after all.

-Ben
Mar 11 2005
next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 I was also pretty sceptical about the usefulness of $/length/whatever. 
 Then I started grepping around to write a post about how silly the feature 
 is and I realized it is more common than I thought. It seemed like about 
 1/3 to 1/2 of indexing expressions would involve the length.


Hmm. I don't know which grep I was talking about there. The numbers weren't 
that high. I think it was a majority of those involving "length" but I don't 
think I grepped for all indexing expressions.
Anyway, I got the data from the CIA so it must be right ;-)
Mar 11 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d0s2vk$1rgs$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message
 news:onv6vwm3agbo$.1ezjtrb8uag1.dlg 40tude.net...

 On Thu, 10 Mar 2005 23:03:58 -0600, J C Calvarese wrote:


 Ben Hinkle wrote:

 I don't know if this has been already proposed but I was pondering the
 "negative index" and the "missing index" proposals and it occurred to








me

 that a place-holder that would be (a) an identifier, (b) unobtrusive








and

 (c)
 unlikely to be used by a real coder is an underscore. I grepped phobos
 for
 some examples of a[a.length] and replaced them with a[_] to get a feel
 for
 how it would look. At one point Walter proposed making it an error to
 have
 the "magic length identifier" shadow a symbol with the same name - and








I

 think that would catch any yahoo who actually wants to have symbols
 named _

 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];


 I like it. It's clever.


 It is significantly more difficult to see. Not every one has 20-y.o.




eyes

 any more? ;-)


 When surrounded by spaces it should be easier to pick out, but I agree
 visibility is the biggest drawback.


While technically it will work fine, it just doesn't look right. It looks
like an attempt to draw a picture with ASCII art. The visual appearance
matters as much as the technical merits.
Mar 14 2005
parent reply Vathix <vathix dprogramming.com> writes:
 ./std/math2.d: real result = coefficients[_ - 1];


 I like it. It's clever.


 It is significantly more difficult to see. Not every one has 20-y.o.




 eyes

 any more? ;-)


 When surrounded by spaces it should be easier to pick out, but I agree
 visibility is the biggest drawback.


 While technically it will work fine, it just doesn't look right. It looks
 like an attempt to draw a picture with ASCII art. The visual appearance
 matters as much as the technical merits.


hah.   [_.._] looks disturbing.
Mar 14 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Vathix wrote:


 While technically it will work fine, it just doesn't look right. It looks
 like an attempt to draw a picture with ASCII art. The visual appearance
 matters as much as the technical merits.


 
 hah.   [_.._] looks disturbing.


I'm not sure that [$..$] is all good either. Looks a bit... commercial ?
Especially since the compiler pronounces it as "(__dollar)", in errors.

At least [_length .. _length] looks *somewhat* sane, in all the madness.

--anders
Mar 14 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 14 Mar 2005 21:01:31 +0100, Anders F Björklund wrote:


 Vathix wrote:
 

 While technically it will work fine, it just doesn't look right. It looks
 like an attempt to draw a picture with ASCII art. The visual appearance
 matters as much as the technical merits.


 
 hah.   [_.._] looks disturbing.


 
 I'm not sure that [$..$] is all good either. Looks a bit... commercial ?
 Especially since the compiler pronounces it as "(__dollar)", in errors.
 
 At least [_length .. _length] looks *somewhat* sane, in all the madness.
 
 --anders


Except that its not runnable. The first index must be a value from 0 to
array.length-1 
-- 
Derek Parnell
Melbourne, Australia
15/03/2005 7:08:29 AM
Mar 14 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


I'm not sure that [$..$] is all good either. Looks a bit... commercial ?
Especially since the compiler pronounces it as "(__dollar)", in errors.

At least [_length .. _length] looks *somewhat* sane, in all the madness.


 
 Except that its not runnable. The first index must be a value from 0 to
 array.length-1 


Sure it is, you just get an ArrayBoundsError for non-release builds ?

But you are right that $-1 is probably more useful as a starting index.


 import std.stdio;
 int main(char[][] args)
 {
   char[][] str = args[$-1..$];
   writefln(str[0]);
   return 0;
 }


Again, probably better to use "args[args.length-1..args.length]" here.

--anders
Mar 14 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 14 Mar 2005 21:16:54 +0100, Anders F Björklund wrote:

[snip]


 But you are right that $-1 is probably more useful as a starting index.
 

 import std.stdio;
 int main(char[][] args)
 {
   char[][] str = args[$-1..$];
   writefln(str[0]);
   return 0;
 }


 
 Again, probably better to use "args[args.length-1..args.length]" here.


Are you joking or are you sadistic ;-)

-- 
Derek Parnell
Melbourne, Australia
15/03/2005 7:32:49 AM
Mar 14 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


Again, probably better to use "args[args.length-1..args.length]" here.


 
 Are you joking or are you sadistic ;-)


Typical, here one tries to write readfriendly code, and what happens...


 str =  ARGV[-1..-1];
print "$str[0]\n";

Better? :-)

--anders
Mar 14 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 14 Mar 2005 21:48:03 +0100, Anders F Björklund wrote:


 Derek Parnell wrote:
 

Again, probably better to use "args[args.length-1..args.length]" here.


 
 Are you joking or are you sadistic ;-)


 
 Typical, here one tries to write readfriendly code, and what happens...
 

  str =  ARGV[-1..-1];
 print "$str[0]\n";
 
 Better? :-)


LOL...

I was actually thinking more like ...

  str = args[ args.length - 1  ..  args.length ];

or 

  str = args[ $ - 1  ..  $ ];

in other words - whitespace is your friend :D

-- 
Derek
Melbourne, Australia
15/03/2005 9:28:51 AM
Mar 14 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 I was actually thinking more like ...
 
   str = args[ args.length - 1  ..  args.length ];
 
 or 
 
   str = args[ $ - 1  ..  $ ];
 
 in other words - whitespace is your friend :D


Ah, OK!
Then I was going in the right direction after all... :-)

How does this (actual) code look to you then:
m_keys = m_keys[0 .. i] ~ m_keys[i+1 .. m_keys.length];

I was wonder whether I should do a "pop()" inline or not,
but decided it was simple enough to leave as a one-liner ?

--anders
Mar 14 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 14 Mar 2005 23:38:37 +0100, Anders F Björklund wrote:


 Derek Parnell wrote:
 

 I was actually thinking more like ...
 
   str = args[ args.length - 1  ..  args.length ];
 
 or 
 
   str = args[ $ - 1  ..  $ ];
 
 in other words - whitespace is your friend :D


 
 Ah, OK!
 Then I was going in the right direction after all... :-)
 
 How does this (actual) code look to you then:
 m_keys = m_keys[0 .. i] ~ m_keys[i+1 .. m_keys.length];


Well, seeing you asked, I'd prefer ...



only because the '$' is faster to grok than "m_keys.length". The eye has to
read the 13 characters and register it in the brain, in context, before it
can click on what the coder is trying to say. The '$' makes the same point
in a much faster manner.

I guess though, its whatever one becomes accustomed to reading.


 I was wonder whether I should do a "pop()" inline or not,
 but decided it was simple enough to leave as a one-liner ?


Actually, I'd go with a "pop()" because it is a more concise expression of
the coder's intention. In other words, a reader of the code will more
quickly understand what you are trying to say with "pop()" than reading and
making sense of the longer statement.

I try to code for human readers rather than for compilers.

-- 
Derek
Melbourne, Australia
15/03/2005 10:30:08 AM
Mar 14 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 Well, seeing you asked, I'd prefer ...
 

 
 only because the '$' is faster to grok than "m_keys.length". The eye has to
 read the 13 characters and register it in the brain, in context, before it
 can click on what the coder is trying to say. The '$' makes the same point
 in a much faster manner.


Okay, I will consider it - once my GDC supports it :-)


 Actually, I'd go with a "pop()" because it is a more concise expression of
 the coder's intention. In other words, a reader of the code will more
 quickly understand what you are trying to say with "pop()" than reading and
 making sense of the longer statement.
 
 I try to code for human readers rather than for compilers.


The code (i.e. the "pop" function) was only used twice.

--anders
Mar 14 2005
prev sibling next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Ben Hinkle wrote:

 I don't know if this has been already proposed but I was pondering the 
 "negative index" and the "missing index" proposals and it occurred to me 
 that a place-holder that would be (a) an identifier, (b) unobtrusive and (c) 
 unlikely to be used by a real coder is an underscore. I grepped phobos for 
 some examples of a[a.length] and replaced them with a[_] to get a feel for 
 how it would look. At one point Walter proposed making it an error to have 
 the "magic length identifier" shadow a symbol with the same name - and I 
 think that would catch any yahoo who actually wants to have symbols named _
 
 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];
 ./std/math2.d: if (s[_ - 1] == 'h')
 ./std/path.d:     return fullname[i .. _];
 ./std/path.d: return fullname[i .. _];
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: fullname = fullname[0 .. _ - existing.length] ~ ext;
 ./std/path.d:    return d.length < path.length && path[d.length] == sep[0];
 ./std/path.d:  else if (p1[_ - 1] == '\\')
 ./std/path.d:      p = p1 ~ p2[1 .. _];
 ./std/path.d:     else if (p1[_ - 1] == '\\')
 ./std/path.d: else if (p1[_ - 1] == sep[0])
 ./std/path.d:   if (fnmatch(name[j .. _], pattern[pi + 1 .. _]))
 ./std/regexp.d: result ~= string[p .. _];
 [snip many more examples from phobos] 
 
 


Of all the alternatives, this ones seems to be a better choice.  It's 
definitely not perfect, but perfect is hard to come by.

And many thanks to Walter for being so willing to experiment recently. 
I was absolutely shocked to see the changes in the last dmd release.  It 
sure is nice to have things "try-before-you-buy!"

_JJR_
Mar 10 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
John Reimer wrote:

 Ben Hinkle wrote:
 

 I don't know if this has been already proposed but I was pondering the 
 "negative index" and the "missing index" proposals and it occurred to 
 me that a place-holder that would be (a) an identifier, (b) 
 unobtrusive and (c) unlikely to be used by a real coder is an 
 underscore. I grepped phobos for some examples of a[a.length] and 
 replaced them with a[_] to get a feel for how it would look. At one 
 point Walter proposed making it an error to have the "magic length 
 identifier" shadow a symbol with the same name - and I think that 
 would catch any yahoo who actually wants to have symbols named _

 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];
 ./std/math2.d: if (s[_ - 1] == 'h')
 ./std/path.d:     return fullname[i .. _];
 ./std/path.d: return fullname[i .. _];
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: fullname = fullname[0 .. _ - existing.length] ~ ext;
 ./std/path.d:    return d.length < path.length && path[d.length] == 
 sep[0];
 ./std/path.d:  else if (p1[_ - 1] == '\\')
 ./std/path.d:      p = p1 ~ p2[1 .. _];
 ./std/path.d:     else if (p1[_ - 1] == '\\')
 ./std/path.d: else if (p1[_ - 1] == sep[0])
 ./std/path.d:   if (fnmatch(name[j .. _], pattern[pi + 1 .. _]))
 ./std/regexp.d: result ~= string[p .. _];
 [snip many more examples from phobos]


 
 Of all the alternatives, this ones seems to be a better choice.  It's 
 definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be the 
best choice." :-P

-JJR
Mar 10 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 10 Mar 2005 22:35:49 -0800, John Reimer wrote:


 John Reimer wrote:

 Ben Hinkle wrote:
 

 I don't know if this has been already proposed but I was pondering the 
 "negative index" and the "missing index" proposals and it occurred to 
 me that a place-holder that would be (a) an identifier, (b) 
 unobtrusive and (c) unlikely to be used by a real coder is an 
 underscore. I grepped phobos for some examples of a[a.length] and 
 replaced them with a[_] to get a feel for how it would look. At one 
 point Walter proposed making it an error to have the "magic length 
 identifier" shadow a symbol with the same name - and I think that 
 would catch any yahoo who actually wants to have symbols named _

 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];
 ./std/math2.d: if (s[_ - 1] == 'h')
 ./std/path.d:     return fullname[i .. _];
 ./std/path.d: return fullname[i .. _];
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: fullname = fullname[0 .. _ - existing.length] ~ ext;
 ./std/path.d:    return d.length < path.length && path[d.length] == 
 sep[0];
 ./std/path.d:  else if (p1[_ - 1] == '\\')
 ./std/path.d:      p = p1 ~ p2[1 .. _];
 ./std/path.d:     else if (p1[_ - 1] == '\\')
 ./std/path.d: else if (p1[_ - 1] == sep[0])
 ./std/path.d:   if (fnmatch(name[j .. _], pattern[pi + 1 .. _]))
 ./std/regexp.d: result ~= string[p .. _];
 [snip many more examples from phobos]


 
 Of all the alternatives, this ones seems to be a better choice.  It's 
 definitely not perfect, but perfect is hard to come by.


 
 Grammar correction: "Of all the alternatives, this one seems to be the 
 best choice." :-P


No it doesn't ;-) 

-- 
Derek Parnell
Melbourne, Australia
11/03/2005 11:09:16 PM
Mar 11 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Derek Parnell wrote:


Of all the alternatives, this ones seems to be a better choice.  It's 
definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be the 
best choice." :-P


 
 
 No it doesn't ;-) 
 


Ha! :-)
Mar 11 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:d0sdva$27g1$1 digitaldaemon.com...

 Derek Parnell wrote:


Of all the alternatives, this ones seems to be a better choice. 
It's definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be 
the best choice." :-P



 No it doesn't ;-)


 Ha! :-)


Are we yet ready to agree that neither $ not _ not $length have survived 
enough criticism to pass, and that therefore all should be deprecated, 
and we should, now, move on to more significant flaws in the language.

I say we all give Walter a hearty slap on the back for moving to the 
try-it-out paradigm, and declare this first one a success (albeit that 
it's a success in the negative).

Matthew
Mar 11 2005
next sibling parent reply Jon Andrew <Jon_member pathlink.com> writes:
In article <d0t00q$2rl8$1 digitaldaemon.com>, Matthew says...

"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:d0sdva$27g1$1 digitaldaemon.com...

 Derek Parnell wrote:


Of all the alternatives, this ones seems to be a better choice. 
It's definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be 
the best choice." :-P



 No it doesn't ;-)


 Ha! :-)


Are we yet ready to agree that neither $ not _ not $length have survived 
enough criticism to pass, and that therefore all should be deprecated, 
and we should, now, move on to more significant flaws in the language.

I say we all give Walter a hearty slap on the back for moving to the 
try-it-out paradigm, and declare this first one a success (albeit that 
it's a success in the negative).

Matthew


Aye, typing out arr.length really isn't such a big hassle anyway, is it?

Jon
Mar 11 2005
next sibling parent Kris <Kris_member pathlink.com> writes:
In article <d0t1h6$4og$1 digitaldaemon.com>, Jon Andrew says...

In article <d0t00q$2rl8$1 digitaldaemon.com>, Matthew says...

"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:d0sdva$27g1$1 digitaldaemon.com...

 Derek Parnell wrote:


Of all the alternatives, this ones seems to be a better choice. 
It's definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be 
the best choice." :-P



 No it doesn't ;-)


 Ha! :-)


Are we yet ready to agree that neither $ not _ not $length have survived 
enough criticism to pass, and that therefore all should be deprecated, 
and we should, now, move on to more significant flaws in the language.

I say we all give Walter a hearty slap on the back for moving to the 
try-it-out paradigm, and declare this first one a success (albeit that 
it's a success in the negative).

Matthew


Aye, typing out arr.length really isn't such a big hassle anyway, is it?

Jon


Nope - it's not. 

The shorthand notation was introduced to help with templates, where having a
'tmp' for the addressed array is just not convenient. Thus, the implied 'length'
was born. It is but for that purpose only, and just happened to provide for a
shortcut in other ways. Would have been great other than the problems it caused
:-)

Frankly, I'm more concerned about the other tags (such as _argptr, __file__,
etc)
Mar 11 2005
prev sibling parent xs0 <xs0 xs0.com> writes:
 Aye, typing out arr.length really isn't such a big hassle anyway, is it?


That isn't, but if you have

foo(somefunc(some,params)[length-1]);

you need a temporary var to do it, which is a hassle (keeps the 
reference, too, so can't be GC'ed unless you null it, which is even more 
hassle)


xs0
Mar 14 2005
prev sibling next sibling parent reply Kris <Kris_member pathlink.com> writes:
Forgive me, but I didn't see much, if any, criticism of the following which was
posted early on:

$length
$argptr
$arguments
$file
$line
$timestamp

or the alternative:

 length
 argptr
 arguments
 file
 line
 timestamp

Don't wish to drag this out any longer than it has to be, but, please remind me
of the arguments against collating all such meta-tags together under one roof
.. there's a number of benefits in adopting the above, right? 

I'm certainly not too fond of adopting a __NAME__ approach for __file__ et. al.,
so what are the alternatives there? And then what about _arguments and _argptr?

Does this point out a problem with NG's in general? ~ perhaps all too often the
bigger picture is lost to the winds?

- Kris



In article <d0t00q$2rl8$1 digitaldaemon.com>, Matthew says...

"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:d0sdva$27g1$1 digitaldaemon.com...

 Derek Parnell wrote:


Of all the alternatives, this ones seems to be a better choice. 
It's definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be 
the best choice." :-P



 No it doesn't ;-)


 Ha! :-)


Are we yet ready to agree that neither $ not _ not $length have survived 
enough criticism to pass, and that therefore all should be deprecated, 
and we should, now, move on to more significant flaws in the language.

I say we all give Walter a hearty slap on the back for moving to the 
try-it-out paradigm, and declare this first one a success (albeit that 
it's a success in the negative).

Matthew
Mar 11 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 11 Mar 2005 21:18:40 +0000 (UTC), Kris wrote:


 Forgive me, but I didn't see much, if any, criticism of the following which was
 posted early on:
 
 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp
 
 or the alternative:
 
  length
  argptr
  arguments
  file
  line
  timestamp
 
 Don't wish to drag this out any longer than it has to be, but, please remind me
 of the arguments against collating all such meta-tags together under one roof
 .. there's a number of benefits in adopting the above, right? 
 
 I'm certainly not too fond of adopting a __NAME__ approach for __file__ et.
al.,
 so what are the alternatives there? And then what about _arguments and _argptr?


Because they add a more consistent approach to the whole issue, I'd add my
support to this type of approach.


-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
12/03/2005 8:24:58 AM
Mar 11 2005
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Derek Parnell wrote:

 On Fri, 11 Mar 2005 21:18:40 +0000 (UTC), Kris wrote:
 
 

Forgive me, but I didn't see much, if any, criticism of the following which was
posted early on:

$length
$argptr
$arguments
$file
$line
$timestamp

or the alternative:

 length
 argptr
 arguments
 file
 line
 timestamp

Don't wish to drag this out any longer than it has to be, but, please remind me
of the arguments against collating all such meta-tags together under one roof
.. there's a number of benefits in adopting the above, right? 

I'm certainly not too fond of adopting a __NAME__ approach for __file__ et. al.,
so what are the alternatives there? And then what about _arguments and _argptr?


 
 
 Because they add a more consistent approach to the whole issue, I'd add my
 support to this type of approach.
 
 


I like this stuff, too.

Lars Ivar Igesund
Mar 11 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Kris" <Kris_member pathlink.com> wrote in message 
news:d0t1vg$9nd$1 digitaldaemon.com...

 Forgive me, but I didn't see much, if any, criticism of the following 
 which was
 posted early on:

 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp

 or the alternative:

  length
  argptr
  arguments
  file
  line
  timestamp

 Don't wish to drag this out any longer than it has to be, but, please 
 remind me
 of the arguments against collating all such meta-tags together under 
 one roof
 .. there's a number of benefits in adopting the above, right?

 I'm certainly not too fond of adopting a __NAME__ approach for 
 __file__ et. al.,
 so what are the alternatives there? And then what about _arguments and 
 _argptr?

 Does this point out a problem with NG's in general? ~ perhaps all too 
 often the
 bigger picture is lost to the winds?


Well, I still think that __FILE__ is a different kind of fish to 
$length, but not so much as I'd be motivated to (further) argue the 
point.

Were the consensus to be that the above $-prefixed list be 
representative of a general strategy for various meta-ish (meta's the 
wrong word, I know, given MP) things, then I can live with it, and we 
can move on to bigger and badder problems.
Mar 11 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Sat, 12 Mar 2005 08:46:19 +1100, Matthew wrote:


 "Kris" <Kris_member pathlink.com> wrote in message 
 news:d0t1vg$9nd$1 digitaldaemon.com...

 Forgive me, but I didn't see much, if any, criticism of the following 
 which was
 posted early on:

 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp

 or the alternative:

  length
  argptr
  arguments
  file
  line
  timestamp

 Don't wish to drag this out any longer than it has to be, but, please 
 remind me
 of the arguments against collating all such meta-tags together under 
 one roof
 .. there's a number of benefits in adopting the above, right?

 I'm certainly not too fond of adopting a __NAME__ approach for 
 __file__ et. al.,
 so what are the alternatives there? And then what about _arguments and 
 _argptr?

 Does this point out a problem with NG's in general? ~ perhaps all too 
 often the
 bigger picture is lost to the winds?


 
 Well, I still think that __FILE__ is a different kind of fish to 
 $length, but not so much as I'd be motivated to (further) argue the 
 point.
 
 Were the consensus to be that the above $-prefixed list be 
 representative of a general strategy for various meta-ish (meta's the 
 wrong word, I know, given MP) things, then I can live with it, and we 
 can move on to bigger and badder problems.


Okay by me.

-- 
Derek Parnell
Melbourne, Australia
12/03/2005 8:57:45 AM
Mar 11 2005
prev sibling next sibling parent Kris <Kris_member pathlink.com> writes:
In article <d0t3jc$h2o$1 digitaldaemon.com>, Matthew says...
<snip>

Were the consensus to be that the above $-prefixed list be 
representative of a general strategy for various meta-ish (meta's the 
wrong word, I know, given MP) things, then I can live with it, and we 
can move on to bigger and badder problems. 


Good to explicitly point that out, and I believe that's the general idea here (a
strategic move, rather than the cutest one). 

So, yeah ~ I'm on board with this too.
Mar 11 2005
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 12 Mar 2005 08:46:19 +1100, Matthew  
<admin stlsoft.dot.dot.dot.dot.org> wrote:

 "Kris" <Kris_member pathlink.com> wrote in message
 news:d0t1vg$9nd$1 digitaldaemon.com...

 Forgive me, but I didn't see much, if any, criticism of the following
 which was
 posted early on:

 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp

 or the alternative:

  length
  argptr
  arguments
  file
  line
  timestamp

 Don't wish to drag this out any longer than it has to be, but, please
 remind me
 of the arguments against collating all such meta-tags together under
 one roof
 .. there's a number of benefits in adopting the above, right?

 I'm certainly not too fond of adopting a __NAME__ approach for
 __file__ et. al.,
 so what are the alternatives there? And then what about _arguments and
 _argptr?

 Does this point out a problem with NG's in general? ~ perhaps all too
 often the
 bigger picture is lost to the winds?


 Well, I still think that __FILE__ is a different kind of fish to
 $length, but not so much as I'd be motivated to (further) argue the
 point.

 Were the consensus to be that the above $-prefixed list be
 representative of a general strategy for various meta-ish (meta's the
 wrong word, I know, given MP) things, then I can live with it, and we
 can move on to bigger and badder problems.


Count me in. I think the pro's of using a meta prefix of $ or   outweighs  
the cons.

Regan
Mar 13 2005
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Kris wrote:

 Forgive me, but I didn't see much, if any, criticism of the following which was
 posted early on:
 
 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp
 
 or the alternative:
 
  length
  argptr
  arguments
  file
  line
  timestamp
 
 Don't wish to drag this out any longer than it has to be, but, please remind me
 of the arguments against collating all such meta-tags together under one roof
 .. there's a number of benefits in adopting the above, right? 
 
 I'm certainly not too fond of adopting a __NAME__ approach for __file__ et.
al.,
 so what are the alternatives there? And then what about _arguments and _argptr?
 
 Does this point out a problem with NG's in general? ~ perhaps all too often the
 bigger picture is lost to the winds?
 
 - Kris
 


I like

 length
 argptr
 arguments

just because $ reminds me of money, or some sort of string. and   
reminds me of something like address or location.

maybe i am just the lone sheep that likes the  , but to me it looks 
simple, elegent, smooth and circular. Or like a winding spiral consuming 
itself.

As for criticism? Well I got none other than it eats up an unused 
symbol. But it makes sense, and wraps all those 'weird' keywords into a 
nice little bundle.


 
 
 In article <d0t00q$2rl8$1 digitaldaemon.com>, Matthew says...
 

"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:d0sdva$27g1$1 digitaldaemon.com...


Derek Parnell wrote:



Of all the alternatives, this ones seems to be a better choice. 
It's definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be 
the best choice." :-P



No it doesn't ;-)


Ha! :-)


Are we yet ready to agree that neither $ not _ not $length have survived 
enough criticism to pass, and that therefore all should be deprecated, 
and we should, now, move on to more significant flaws in the language.

I say we all give Walter a hearty slap on the back for moving to the 
try-it-out paradigm, and declare this first one a success (albeit that 
it's a success in the negative).

Matthew
Mar 11 2005
prev sibling next sibling parent "Les Baker" <les_baker bellsouthREMOVETHIS.net> writes:
"Kris" <Kris_member pathlink.com> wrote in message
news:d0t1vg$9nd$1 digitaldaemon.com...

 Forgive me, but I didn't see much, if any, criticism of the following


which was

 posted early on:

 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp

 or the alternative:

  length
  argptr
  arguments
  file
  line
  timestamp


I hate to be "me-too"-ish, but I've lurked around a while, and w.r.t. the
"length" debate, I like this approach best, because it at least makes the
"uglification" consistent.

The big disadvantage is that the dollar or at would imply a relation between
the identifiers where there is not. But I think that the disambiguation/less
namespace pollution outweighs any disadvantages.

As an aside, most times in larger projects that I use "length" in a
variable, it is prefixed (ex. "fileLength"). But I think one of the stated
goals for D was to make "quick-n-dirty" coding of small programs easier, and
the utility/ease of using "length" by itself is very high.

Just my 0.02 USD,
Les Baker
Mar 11 2005
prev sibling next sibling parent John Demme <me teqdruid.com> writes:
Considering I was (at least one of) the people who suggested it, I'm on 
board.  Walter?

John Demme

Kris wrote:

 Forgive me, but I didn't see much, if any, criticism of the following which was
 posted early on:
 
 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp
 
 or the alternative:
 
  length
  argptr
  arguments
  file
  line
  timestamp
 
 Don't wish to drag this out any longer than it has to be, but, please remind me
 of the arguments against collating all such meta-tags together under one roof
 .. there's a number of benefits in adopting the above, right? 
 
 I'm certainly not too fond of adopting a __NAME__ approach for __file__ et.
al.,
 so what are the alternatives there? And then what about _arguments and _argptr?
 
 Does this point out a problem with NG's in general? ~ perhaps all too often the
 bigger picture is lost to the winds?
 
 - Kris
 
 
 
 In article <d0t00q$2rl8$1 digitaldaemon.com>, Matthew says...
 

"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:d0sdva$27g1$1 digitaldaemon.com...


Derek Parnell wrote:



Of all the alternatives, this ones seems to be a better choice. 
It's definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be 
the best choice." :-P



No it doesn't ;-)


Ha! :-)


Are we yet ready to agree that neither $ not _ not $length have survived 
enough criticism to pass, and that therefore all should be deprecated, 
and we should, now, move on to more significant flaws in the language.

I say we all give Walter a hearty slap on the back for moving to the 
try-it-out paradigm, and declare this first one a success (albeit that 
it's a success in the negative).

Matthew
Mar 12 2005
prev sibling next sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Kris schrieb:

 Forgive me, but I didn't see much, if any, criticism of the following which was
 posted early on:
 
 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp


I think, this is the cleanest approach so far. The list can easily be 
extended arbitrarily for anything that cannot be parsed quite like a 
regular identifier but is not important enough to be a keyword.

Furthermore, this approach still leaves quite some room for $ to be used 
for other big issues.

Anyhow: I would still prefer $len over $length for reasons I have given 
before.

Ciao,
Norbert
Mar 13 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


 I'm certainly not too fond of adopting a __NAME__ approach for __file__ et.
al.,
 so what are the alternatives there? And then what about _arguments and _argptr?



 I think, this is the cleanest approach so far. The list can easily be 
 extended arbitrarily for anything that cannot be parsed quite like a 
 regular identifier but is not important enough to be a keyword.


But then again, what's the big difference between _ and $ in that case?

Why is:

 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp


Better than:

 _length
 _argptr
 _arguments
 __FILE__
 __LINE__
 __TIMESTAMP__


("length" and "$" are both evil and must be thrown down a cliff,
  _length is only useful for templates - otherwise use AA.length?)

I just don't see the point of changing it, into something so similar ?
But I'm pretty tired of this thread so I'll just wait it out, myself...


 Furthermore, this approach still leaves quite some room for $ to be used 
 for other big issues.


$   makes it look like variables to programmers used to shell and Perl, 
just like the `` strings make it look like it runs external programs...

I definitely prefer _name, __NAME__ and r"" over these "alternatives".
Can't say that I plan to use *any* of them in most of the regular code?

They're all pretty specialized, IMHO. (for Templates/Variadics/Logging)
*I* think that you should save $ and   for something else completely...

--anders
Mar 13 2005
parent reply kris <fu bar.org> writes:
Anders;

The difference is small but quite significant: '_' is legal within 
user-identifiers (variables, function names, etc) whereas '$' and ' ' 
are not.

By using a '$' or ' ' as a prefix, Walter can happily extend these 'meta 
tags' without fear of breaking any exisiting code (conflicts in the 
user-namespace) and without having to create a reserved word. Yes, the 
approach has perhaps a touch of compromise to it, but it's a practical 
and forward-thinking resolution. That's more important than an aesthetic 
preference.

- Kris


Anders F Björklund wrote:

 Norbert Nemec wrote:
 

 I'm certainly not too fond of adopting a __NAME__ approach for 
 __file__ et. al.,
 so what are the alternatives there? And then what about _arguments and 
 _argptr?


 
 

 I think, this is the cleanest approach so far. The list can easily be 
 extended arbitrarily for anything that cannot be parsed quite like a 
 regular identifier but is not important enough to be a keyword.


 
 
 But then again, what's the big difference between _ and $ in that case?
 
 Why is:
 

 $length
 $argptr
 $arguments
 $file
 $line
 $timestamp


 
 
 Better than:
 

 _length
 _argptr
 _arguments
 __FILE__
 __LINE__
 __TIMESTAMP__


 
 
 ("length" and "$" are both evil and must be thrown down a cliff,
  _length is only useful for templates - otherwise use AA.length?)
 
 I just don't see the point of changing it, into something so similar ?
 But I'm pretty tired of this thread so I'll just wait it out, myself...
 

 Furthermore, this approach still leaves quite some room for $ to be 
 used for other big issues.


 
 
 $   makes it look like variables to programmers used to shell and Perl, 
 just like the `` strings make it look like it runs external programs...
 
 I definitely prefer _name, __NAME__ and r"" over these "alternatives".
 Can't say that I plan to use *any* of them in most of the regular code?
 
 They're all pretty specialized, IMHO. (for Templates/Variadics/Logging)
 *I* think that you should save $ and   for something else completely...
 
 --anders
Mar 13 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
kris wrote:


 The difference is small but quite significant: '_' is legal within 
 user-identifiers (variables, function names, etc) whereas '$' and ' ' 
 are not.


Guess I've just been using C too long. Starting a user identifier
with underscore has always been done at your own peril, as those
used to be reserved for compiler internals (usually macros, there)

However, messing with "length" crossed at least my own boundaries...


 By using a '$' or ' ' as a prefix, Walter can happily extend these 'meta 
 tags' without fear of breaking any exisiting code (conflicts in the 
 user-namespace) and without having to create a reserved word.


Well, *theoretically* one could also ban _ from starting user vars ?
(since _arguments and _argptr were there, I thought it was implied)
Anyway, meta tags doesn't sound all bad. Just thought it was overkill.

Until the "next big thing" shows up, I don't think it needs changing...

--anders
Mar 13 2005
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Kris wrote:

 Forgive me, but I didn't see much, if any, criticism of the following which was
 posted early on:
 
 $length


I prefer the shorter variant "$len", but I can live with "$length".

Either way is much better than what we were stuck with a couple months 
ago when an array length was hiding other lengths. That was an error 
obscurer if I ever saw one.


 $argptr
 $arguments
 $file
 $line
 $timestamp
 
 or the alternative:
 
  length
  argptr
  arguments
  file
  line
  timestamp


Either $ or   looks good to me.


 Don't wish to drag this out any longer than it has to be, but, please remind me
 of the arguments against collating all such meta-tags together under one roof
 .. there's a number of benefits in adopting the above, right? 
 
 I'm certainly not too fond of adopting a __NAME__ approach for __file__ et.
al.,
 so what are the alternatives there? And then what about _arguments and _argptr?


One underscore is cute. Two are a lack of creativity. ;)


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Mar 13 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Kris" <Kris_member pathlink.com> wrote in message
news:d0t1vg$9nd$1 digitaldaemon.com...

 I'm certainly not too fond of adopting a __NAME__ approach for __file__


et. al.,

 so what are the alternatives there?


I'm not too fond of its look either, but things like __FILE__ and __LINE__
are so deeply embedded in the psyche, it's instantly recognizable even for
people who've never seen D before. That's a powerful current to swim
against. D can diverge in appearance from C++ up to a point, I don't know
where that point is, but once we're past it then D may look so different
that people will be put off from learning it and dump it into the Eiffel
bin.

I'm not really sure why Eiffel failed to catch on, but it's visual
appearance I find personally off-putting.


 And then what about _arguments and _argptr?


I'd rather stick with _ as a prefix rather than $, just because it's
longstanding C tradition for naming internal system variables.
Mar 14 2005
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <d14n7i$2aa9$1 digitaldaemon.com>, Walter says...

"Kris" <Kris_member pathlink.com> wrote in message
news:d0t1vg$9nd$1 digitaldaemon.com...

 I'm certainly not too fond of adopting a __NAME__ approach for __file__


et. al.,

 so what are the alternatives there?


I'm not too fond of its look either, but things like __FILE__ and __LINE__
are so deeply embedded in the psyche, it's instantly recognizable even for
people who've never seen D before. That's a powerful current to swim
against. D can diverge in appearance from C++ up to a point, I don't know
where that point is, but once we're past it then D may look so different
that people will be put off from learning it and dump it into the Eiffel
bin.


For someone such as myself who doesn't bring much C baggage to my D perspective
__FILE__ and __LINE__ looks more like a failed attempt at ASCII art than
programming. Please don't take D down this road! 

Either $ or   looks cool to me.


I'm not really sure why Eiffel failed to catch on, but it's visual
appearance I find personally off-putting.


 And then what about _arguments and _argptr?


I'd rather stick with _ as a prefix rather than $, just because it's
longstanding C tradition for naming internal system variables.


I thought outdated long-standing C traditions are much of the reason for D. (C
doesn't need objects, garbage collections, modules, array slicing, templates,
mixins, and operator overloading, so neither does D?)

jcc7
Mar 14 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
J C Calvarese wrote:


 For someone such as myself who doesn't bring much C baggage to my D perspective
 __FILE__ and __LINE__ looks more like a failed attempt at ASCII art than
 programming. Please don't take D down this road! 


If anything, it was already *on* that road. The question is whether
these "once-in-a-blue-moon" variables are reason enough to leave it ?


 Either $ or   looks cool to me.


Me too, so my Perl code uses a lot of both of them. And % too... :-)

Just that there seemed like no really good reason to add them to D,
just because Walter used "length" instead of "_length" in DMD 0.99 ?


 I thought outdated long-standing C traditions are much of the reason for D. (C
 doesn't need objects, garbage collections, modules, array slicing, templates,
 mixins, and operator overloading, so neither does D?)


I'm not sure what replacing one non-alpha character (_) with another
arbitrary choice ($ or  ) has to do with any of those new D features ?

Just document "don't use vars starting with underscore", and move on...

--anders
Mar 14 2005
next sibling parent John Demme <me teqdruid.com> writes:
Anders F Björklund wrote:

 J C Calvarese wrote:
 

 For someone such as myself who doesn't bring much C baggage to my D 
 perspective




Yes!  Not everyone here is coming from C.  In fact, I learned D before I 
learned C! (I'm learning C now, and not enjoying it)


 __FILE__ and __LINE__ looks more like a failed attempt at ASCII art than
 programming. Please don't take D down this road! 


 
 
 If anything, it was already *on* that road. The question is whether
 these "once-in-a-blue-moon" variables are reason enough to leave it ?
 

 Either $ or   looks cool to me.


 
 
 Me too, so my Perl code uses a lot of both of them. And % too... :-)
 
 Just that there seemed like no really good reason to add them to D,
 just because Walter used "length" instead of "_length" in DMD 0.99 ?
 

 I thought outdated long-standing C traditions are much of the reason 
 for D. (C
 doesn't need objects, garbage collections, modules, array slicing, 
 templates,
 mixins, and operator overloading, so neither does D?)


 
 
 I'm not sure what replacing one non-alpha character (_) with another
 arbitrary choice ($ or  ) has to do with any of those new D features ?
 
 Just document "don't use vars starting with underscore", and move on...


Since when has a documented recommendation stopped programmers from 
doing it?  Why do you think the expression RTFM is so popular?  I'd only 
support using _ if it wasn't a valid identifier starter.

John Demme
Mar 14 2005
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <d14r78$2baj$3 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

J C Calvarese wrote:


 For someone such as myself who doesn't bring much C baggage to my D perspective
 __FILE__ and __LINE__ looks more like a failed attempt at ASCII art than
 programming. Please don't take D down this road! 


If anything, it was already *on* that road. The question is whether
these "once-in-a-blue-moon" variables are reason enough to leave it ?


 Either $ or   looks cool to me.


Me too, so my Perl code uses a lot of both of them. And % too... :-)

Just that there seemed like no really good reason to add them to D,
just because Walter used "length" instead of "_length" in DMD 0.99 ?


 I thought outdated long-standing C traditions are much of the reason for D. (C
 doesn't need objects, garbage collections, modules, array slicing, templates,
 mixins, and operator overloading, so neither does D?)


I'm not sure what replacing one non-alpha character (_) with another
arbitrary choice ($ or  ) has to do with any of those new D features ?


I'll try to clarify my intended point.

If the C way was good enough, none of those features would have been added. It
might be a poor point, but I still can't see the justification for choosing
"__FILE__" when "$file" is available. Is it *that* hard to parse?

It's one thing to take inspiration from C. It's quite another to be
straitjacketed by its mistakes.


Just document "don't use vars starting with underscore", and move on...


Just like the keep all filenames lowercase convention? Conventions are too
easily discarded by those with another opinion. If the compiler will enforce it,
it'd be a much better suggestion IMO. I never felt the need to initiate an
identifier with a couple underscores. It's still quite ugly (and LOUD) though.


--anders


jcc7
Mar 14 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
J C Calvarese wrote:


 If the C way was good enough, none of those features would have been added. It
 might be a poor point, but I still can't see the justification for choosing
 "__FILE__" when "$file" is available. Is it *that* hard to parse?


I see what you mean, but I think that "__FILE__" has a Pro in that
it is recognized by C/C++ programmers, and that "$file" has a Con in
that it is recognized by Perl/Shell programmers (as a plain variable)

And, again, I don't think that it'll be used all that much anyway ?


 It's one thing to take inspiration from C. It's quite another to be
 straitjacketed by its mistakes.


Well, it's not exactly the first time D has said "I'm with stupid" ?

C:      _Bool
D:      bit
C++:    bool
Java:   boolean

C:      char *
D:      char[]
C++:    string
Java:   String

I'm not saying any of those are relevant here, just that it is not
the first (and probably not the last) that D chooses to work like C ?
(I found it surprising to "go back" at first, but I don't anymore...)

Since I happen to like C still, I don't think it's a bad thing. Only.
--anders
Mar 14 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 14 Mar 2005 11:00:51 -0800, Walter wrote:


 "Kris" <Kris_member pathlink.com> wrote in message
 news:d0t1vg$9nd$1 digitaldaemon.com...

 I'm certainly not too fond of adopting a __NAME__ approach for __file__


 et. al.,

 so what are the alternatives there?


 
 I'm not too fond of its look either, but things like __FILE__ and __LINE__
 are so deeply embedded in the psyche, it's instantly recognizable even for
 people who've never seen D before. 


Says you. I don't ever recall using __FILE__ or __LINE__, though I have
seen others use it. It is *not* "deeply embedded in the psyche" of this
little black duck, and as for "instantly recognizable" - I don't think so.
It had to be explained to me when I first saw it. But then maybe I'm a bit
slow.


That's a powerful current to swim
 against. D can diverge in appearance from C++ up to a point, I don't know
 where that point is, but once we're past it then D may look so different
 that people will be put off from learning it and dump it into the Eiffel
 bin.


What? Does C look like its predecessors? If looking different from your
predecessors was a recipe for failure, then why has C been so popular?
Could it be because it was more helpful? Eiffel always appeared to be like
Ada to me, just a bit too 'big' and cumbersome to be having to code with
day in and day out. Your D language *does not* give me that feeling at all.
It needs to be more helpful than C and simple to use at the same time.
Together, this community can get to that point, even if it means moving
farther from a C clone.


 I'm not really sure why Eiffel failed to catch on, but it's visual
 appearance I find personally off-putting.
 

 And then what about _arguments and _argptr?


 
 I'd rather stick with _ as a prefix rather than $, just because it's
 longstanding C tradition for naming internal system variables.


I keep getting confused...are we trying to create the D language or a
variety of C?

-- 
Derek Parnell
Melbourne, Australia
15/03/2005 7:10:37 AM
Mar 14 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 I keep getting confused...are we trying to create the D language or a
 variety of C?


yes
Mar 14 2005
parent Derek Parnell <derek psych.ward> writes:
On Mon, 14 Mar 2005 15:52:59 -0500, Ben Hinkle wrote:


 I keep getting confused...are we trying to create the D language or a
 variety of C?


 
 yes


Ah, good! Well that explains everything nicely. :D

-- 
Derek
Melbourne, Australia
15/03/2005 10:18:25 AM
Mar 14 2005
prev sibling parent reply Kris <Kris_member pathlink.com> writes:
This topic, albeit of relatively trifling importance, is one of the few I can
recall where there was convergence. Although many have their personal aethetic
preferences (and some other concerns) those were ultimately put aside in a bid
to satisfy a greater need. That's quite unusual for this NG, isn't it?

So, we have the following people who voiced an opinion that combining the syntax
was for the greater good overall:

Norbert
Matthew
Kris
John Demme
John Riemer
JCC
Regan
Les Baker
Clayasaurus
Derek Parnell
Lars Ivar
Charlie

I probably missed some people out there. Sorry about that.

Anders suggested reserving a leading '_' instead of a leading '$' or ' '. One
would have to be careful not to conflict with user-space names, so the _prefix
should be reserved to elimintate future conflicts (e.g. one should not be able
to start a variable-name or function with '_').

Ben proposed a single '_' for length alone. I seem to recall him noting that
$length et. al. would be acceptable, but can't find the post now.

All in all, there were no serious detractments from bringing all these together
under one roof ~ and by doing so, adding a bit of consistency and forward
planning for additional 'tags'.

However; Walter now notes that it's not appropriate for  __LINE__ et. al. to
change because of their heritage? Just recently Walter was arguing it wasn't
worth even including them. Odd, no? And _argptr should not change either, due to
its heritage. Exactly how often does the average person use _argptr? 

of course, the use of _arguments has the same problem as [length], although the
chance of a conflict happening is undeniably smaller. But why not clean it up
anyway? Hmmm. 

(Just to clarify: this is about sticking to a consistent naming convention,
across the board, and ensuring that convention does not conflict with user-space
names. It doesn't matter if '_' is adopted instead of ' ' or '$', as long as
that prefix is made illegal in user-space)

Perhaps it's just me. Perhaps I am alone in feeling any effort to draw some
level of convergence is a thorough waste of time. Perhaps JJR was accurate in
his observation that 'voting' has no place or value whatsoever here.

It certainly seems this way. As I said, this is one of the few times I can
recall a convergence on any topic ~ perhaps even a general concensus <gasp>. Yet
it appears to have had zero impact. That's a shame, because if we can't help
shape such seemingly trifling issues, then how can we expect to help shape
larger and/or trickier ones?

I'm disappointed.

- Kris



In article <d14n7i$2aa9$1 digitaldaemon.com>, Walter says...

"Kris" <Kris_member pathlink.com> wrote in message
news:d0t1vg$9nd$1 digitaldaemon.com...

 I'm certainly not too fond of adopting a __NAME__ approach for __file__


et. al.,

 so what are the alternatives there?


I'm not too fond of its look either, but things like __FILE__ and __LINE__
are so deeply embedded in the psyche, it's instantly recognizable even for
people who've never seen D before. That's a powerful current to swim
against. D can diverge in appearance from C++ up to a point, I don't know
where that point is, but once we're past it then D may look so different
that people will be put off from learning it and dump it into the Eiffel
bin.

I'm not really sure why Eiffel failed to catch on, but it's visual
appearance I find personally off-putting.


 And then what about _arguments and _argptr?


I'd rather stick with _ as a prefix rather than $, just because it's
longstanding C tradition for naming internal system variables.
Mar 14 2005
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 Ben proposed a single '_' for length alone. I seem to recall him noting 
 that
 $length et. al. would be acceptable, but can't find the post now.


Heck, I've changed my mind so many times I probably liked all the proposals, 
but for the record here's my current order of preferences:
1) back out the special length behavior entirely
2) _ or _length
3) $length and possibly the other $friends
4) length with a rule about handling shadowed length vars
5) final or $
6) complex arithmetic (the dark horse of the competition!)
Mar 14 2005
prev sibling parent reply =?windows-1252?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:


 Anders suggested reserving a leading '_' instead of a leading '$' or ' '. One
 would have to be careful not to conflict with user-space names, so the _prefix
 should be reserved to elimintate future conflicts (e.g. one should not be able
 to start a variable-name or function with '_').


It can work on the Honor System™, for all that I care...
"Use a leading underscore at your own peril", sort of ?

I just thought it should be mentioned in the documentation.
(meaning that if you don't read that, you just discover it)


 However; Walter now notes that it's not appropriate for  __LINE__ et. al. to
 change because of their heritage? Just recently Walter was arguing it wasn't
 worth even including them. Odd, no? And _argptr should not change either, due
to
 its heritage. Exactly how often does the average person use _argptr? 


I don't think the average person uses __LINE__ either ?
I'm actually with Walter on this one. I haven't seen a
good reason (yet) to change from the current names, to
any new naming system ? Especially not for *these* vars:

Used in logging, if ever:

 __FILE__
 __LINE__
 __DATE__
 __TIME__


Used with variadic args:

 _argptr
 _arguments


Used with some templates:

 _length


Unless there is some new and greater use coming, or any
new variables that was going to be added, I don't think
there is reason enough for any of these little hacks to
change the D language and like introduce a new character ?

Even less reason for any of us here to fight about it...


 of course, the use of _arguments has the same problem as [length], although the
 chance of a conflict happening is undeniably smaller. But why not clean it up
 anyway? Hmmm. 


I hate "length", but "_length" could work (I hate $ too :-) )


 Perhaps it's just me. Perhaps I am alone in feeling any effort to draw some
 level of convergence is a thorough waste of time. Perhaps JJR was accurate in
 his observation that 'voting' has no place or value whatsoever here.


Too bad you feel disappointed, I don't think it was big deal myself...
Just as long as "length" dies a horrible death, I'm fine with either.

And if I knew it was going to start this thread, I'd probably thought it
better *without* the new file/line/timestamp macros in the first place ?

Hey, does anyone want to talk about booleans or strings instead? Oh. :-P

--anders
Mar 14 2005
next sibling parent "Charles" <cee-lo green.com> writes:
 Too bad you feel disappointed, I don't think it was big deal myself...
 Just as long as "length" dies a horrible death, I'm fine with either.


I think his main point was this is one issue ( the only one i can remember
! ) that all of us dedicated D users agree on , and Walter dismisses it with
a wave of the hand, with the reason of backward compatibility to C no less.
It is dissapointing that Walter won't verbally agree , but time has shown us
that even if he doesn't support it vocally , if we make enough stink he will
begrudgingly add it.

I really hope this gets added  , and Im with you on the horrible death of
length ! :).

Charlie

"Anders F Björklund" <afb algonet.se> wrote in message
news:d14v4l$2hjd$1 digitaldaemon.com...

 Kris wrote:


 Anders suggested reserving a leading '_' instead of a leading '$' or




' '. One

 would have to be careful not to conflict with user-space names, so the




_prefix

 should be reserved to elimintate future conflicts (e.g. one should not




be able

 to start a variable-name or function with '_').


 It can work on the Honor System™, for all that I care...
 "Use a leading underscore at your own peril", sort of ?

 I just thought it should be mentioned in the documentation.
 (meaning that if you don't read that, you just discover it)


 However; Walter now notes that it's not appropriate for  __LINE__ et.




al. to

 change because of their heritage? Just recently Walter was arguing it




wasn't

 worth even including them. Odd, no? And _argptr should not change




either, due to

 its heritage. Exactly how often does the average person use _argptr?


 I don't think the average person uses __LINE__ either ?
 I'm actually with Walter on this one. I haven't seen a
 good reason (yet) to change from the current names, to
 any new naming system ? Especially not for *these* vars:

 Used in logging, if ever:

 __FILE__
 __LINE__
 __DATE__
 __TIME__


 Used with variadic args:

 _argptr
 _arguments


 Used with some templates:

 _length


 Unless there is some new and greater use coming, or any
 new variables that was going to be added, I don't think
 there is reason enough for any of these little hacks to
 change the D language and like introduce a new character ?

 Even less reason for any of us here to fight about it...


 of course, the use of _arguments has the same problem as [length],




although the

 chance of a conflict happening is undeniably smaller. But why not clean




it up

 anyway? Hmmm.


 I hate "length", but "_length" could work (I hate $ too :-) )


 Perhaps it's just me. Perhaps I am alone in feeling any effort to draw




some

 level of convergence is a thorough waste of time. Perhaps JJR was




accurate in

 his observation that 'voting' has no place or value whatsoever here.


 Too bad you feel disappointed, I don't think it was big deal myself...
 Just as long as "length" dies a horrible death, I'm fine with either.

 And if I knew it was going to start this thread, I'd probably thought it
 better *without* the new file/line/timestamp macros in the first place ?

 Hey, does anyone want to talk about booleans or strings instead? Oh. :-P

 --anders
Mar 14 2005
prev sibling parent reply "Kris" <fu bar.com> writes:
Inline:

"Anders F Björklund" <afb algonet.se> wrote in message
news:d14v4l$2hjd$1 digitaldaemon.com...

 Kris wrote:


 Anders suggested reserving a leading '_' instead of a leading '$' or




' '. One

 would have to be careful not to conflict with user-space names, so the




_prefix

 should be reserved to elimintate future conflicts (e.g. one should not




be able

 to start a variable-name or function with '_').


 It can work on the Honor System™, for all that I care...
 "Use a leading underscore at your own peril", sort of ?

 I just thought it should be mentioned in the documentation.
 (meaning that if you don't read that, you just discover it)



The problem is that if a new '_foo' tag is introduced, there's no guarantee
that it won't conflict with some variable that may have been used in
somebody's code. Because of that, the '_foo' never gets introduced. This
issue is primarily about reserving a piece of the namespace for expansion.
Without that, you cannot safely introduce new 'tags'. You seem to be saying
that's not worth any effort. I happen to disagree.



 However; Walter now notes that it's not appropriate for  __LINE__ et.




al. to

 change because of their heritage? Just recently Walter was arguing it




wasn't

 worth even including them. Odd, no? And _argptr should not change




either, due to

 its heritage. Exactly how often does the average person use _argptr?


 I don't think the average person uses __LINE__ either ?
 I'm actually with Walter on this one. I haven't seen a
 good reason (yet) to change from the current names, to
 any new naming system ? Especially not for *these* vars:

 Used in logging, if ever:

 __FILE__
 __LINE__
 __DATE__
 __TIME__


 Used with variadic args:

 _argptr
 _arguments


 Used with some templates:

 _length


 Unless there is some new and greater use coming, or any
 new variables that was going to be added, I don't think
 there is reason enough for any of these little hacks to
 change the D language and like introduce a new character ?



Why not make give them all the single '_' prefix, and then reserve said
prefix for compiler use only? That's what's being asked for. The compiler
would have to enforce the illegality of '_' prefixing for everything other
than the recognized tokens.



 Even less reason for any of us here to fight about it...


 of course, the use of _arguments has the same problem as [length],




although the

 chance of a conflict happening is undeniably smaller. But why not clean




it up

 anyway? Hmmm.


 I hate "length", but "_length" could work (I hate $ too :-) )


 Perhaps it's just me. Perhaps I am alone in feeling any effort to draw




some

 level of convergence is a thorough waste of time. Perhaps JJR was




accurate in

 his observation that 'voting' has no place or value whatsoever here.


 Too bad you feel disappointed, I don't think it was big deal myself...
 Just as long as "length" dies a horrible death, I'm fine with either.



I'm disappointed that agreement within this NG, with no strong detraction,
has zero impact in changing the language for the better. The lexer will
probably change anyway, to handle some kind of prefix for [length], why not
fold the others in there at the same time?

Surely it's easier for a user to remember to use one single 'special' prefix
rather than a range of them? ("hmmm, I use two underscores sometimes, one
underscore other times, and no underscores some other times? And some
trailing underscores sometimes?")

Too bad you don't feel consistency is important :-)
Mar 14 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:


 The problem is that if a new '_foo' tag is introduced, there's no guarantee
 that it won't conflict with some variable that may have been used in
 somebody's code. Because of that, the '_foo' never gets introduced. This
 issue is primarily about reserving a piece of the namespace for expansion.
 Without that, you cannot safely introduce new 'tags'. You seem to be saying
 that's not worth any effort. I happen to disagree.


That's cool, I just wondered what the proposed new tags were...

And I did say that _ should be reserved, just wasn't sure if
the D compiler was up to actively protecting them or not ?


 Why not make give them all the single '_' prefix, and then reserve said
 prefix for compiler use only? That's what's being asked for. The compiler
 would have to enforce the illegality of '_' prefixing for everything other
 than the recognized tokens.


If it *was* to have a new namespace, then a single "_" would work here.
That's how it was in C, where _ macros were for the compiler and libs.


 Names that begin with two underscores, such as __STDIO, and names that
 begin with an underscore followed by an upper case letter, such as
 _Entry, can be used as macro names, whether or not a translation unit
 explicitly includes any standard headers. Names that begin with an
 underscore can be defined with external linkage. Avoid writing such
 names in a program that you wish to keep maximally portable.


Since it was C after all, you could still use them. And face the wrath.


 I'm disappointed that agreement within this NG, with no strong detraction,
 has zero impact in changing the language for the better. The lexer will
 probably change anyway, to handle some kind of prefix for [length], why not
 fold the others in there at the same time?


Again, I just didn't see those little vars import enough to change it...

And most seemed to be able to live with _, as long as it was documented?
(including Walter, who said he "would rather stick with _ as a prefix")


 Surely it's easier for a user to remember to use one single 'special' prefix
 rather than a range of them? ("hmmm, I use two underscores sometimes, one
 underscore other times, and no underscores some other times? And some
 trailing underscores sometimes?")
 
 Too bad you don't feel consistency is important :-)


Not *that* important, I guess. Just fell back in "it works like C" mode.

Q: Would adding *both* work ? _file (newcomers) and __FILE__ (oldtimers)

--anders
Mar 14 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d1530o$2md5$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Q: Would adding *both* work ? _file (newcomers) and __FILE__ (oldtimers)


Sure.  but why add two methods when one will suffice?


Sean
Mar 14 2005
prev sibling parent reply "Kris" <fu bar.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d1530o$2md5$1 digitaldaemon.com...

 And I did say that _ should be reserved, just wasn't sure if
 the D compiler was up to actively protecting them or not ?


Nope. And doing so would not be backward compatible with C. This is why the
'$' or ' ' prefix was started. This is just going around in circles :-)



 If it *was* to have a new namespace, then a single "_" would work here.
 That's how it was in C, where _ macros were for the compiler and libs.


But if wasn't enforced. That's where some of the problems stem from, and is
why there were additional kludges made, such as __NAME__



 Names that begin with two underscores, such as __STDIO, and names that
 begin with an underscore followed by an upper case letter, such as
 _Entry, can be used as macro names, whether or not a translation unit
 explicitly includes any standard headers. Names that begin with an
 underscore can be defined with external linkage. Avoid writing such
 names in a program that you wish to keep maximally portable.


 Since it was C after all, you could still use them. And face the wrath.


And D should not enforce the policy? I disagree.


 I'm disappointed that agreement within this NG, with no strong




detraction,

 has zero impact in changing the language for the better. The lexer will
 probably change anyway, to handle some kind of prefix for [length], why




not

 fold the others in there at the same time?


 Again, I just didn't see those little vars import enough to change it...

 And most seemed to be able to live with _, as long as it was documented?
 (including Walter, who said he "would rather stick with _ as a prefix")


It's fine with me if the compiler makes it illegal for other tokens (in
user-space) to start with a '_', and uses the same prefix for all special
tokens.


 Surely it's easier for a user to remember to use one single 'special'




prefix

 rather than a range of them? ("hmmm, I use two underscores sometimes,




one

 underscore other times, and no underscores some other times? And some
 trailing underscores sometimes?")

 Too bad you don't feel consistency is important :-)


 Not *that* important, I guess. Just fell back in "it works like C" mode.


And here's a nice & easy opportunity to simplify some questionable and
inconsistent C syntax. Are you saying that the need for these specific
things to be backward compatible with C is more important than overall
simplicity and consistency of use? Because that's what Walter appears to be
saying.


 Q: Would adding *both* work ? _file (newcomers) and __FILE__ (oldtimers)


Why? It's far better to be consistent. Particularly so when the opportunity
is just sitting there. If you wish to discuss the pros and cons of
consistency, then let's take it out of this thread.
Mar 14 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:


And I did say that _ should be reserved, just wasn't sure if
the D compiler was up to actively protecting them or not ?


 
 Nope. And doing so would not be backward compatible with C. This is why the
 '$' or ' ' prefix was started. This is just going around in circles :-)


I'm on the '_' side then. Even if it is not actively protected...


Since it was C after all, you could still use them. And face the wrath.


 
 And D should not enforce the policy? I disagree.


So it seems. And I don't think this discussion goes much longer.


 And here's a nice & easy opportunity to simplify some questionable and
 inconsistent C syntax. Are you saying that the need for these specific
 things to be backward compatible with C is more important than overall
 simplicity and consistency of use? Because that's what Walter appears to be
 saying.


Adding new things like $ and   to identifiers is a rather big change ?

Maybe even better to take __FILE__ and __DATE__ back out again, then.


Q: Would adding *both* work ? _file (newcomers) and __FILE__ (oldtimers)


 
 Why? It's far better to be consistent. Particularly so when the opportunity
 is just sitting there. If you wish to discuss the pros and cons of
 consistency, then let's take it out of this thread.


Nah, I'm just trying to meddle so we can get on with our lives...

Sorta like how adding the "bool" alias put a truce to *that* war.

--anders
Mar 14 2005
parent reply "Kris" <fu bar.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d155s8$2md5$6 digitaldaemon.com...

 Kris wrote:


And I did say that _ should be reserved, just wasn't sure if
the D compiler was up to actively protecting them or not ?


 Nope. And doing so would not be backward compatible with C. This is why




the

 '$' or ' ' prefix was started. This is just going around in circles :-)


 I'm on the '_' side then. Even if it is not actively protected...


Excellent! That's a far better solution than changing things to be fully
deterministic :-)



Since it was C after all, you could still use them. And face the wrath.


 And D should not enforce the policy? I disagree.


 So it seems. And I don't think this discussion goes much longer.


Agreed :-)



 And here's a nice & easy opportunity to simplify some questionable and
 inconsistent C syntax. Are you saying that the need for these specific
 things to be backward compatible with C is more important than overall
 simplicity and consistency of use? Because that's what Walter appears to




be

 saying.


 Adding new things like $ and   to identifiers is a rather big change ?



Oh. I don't think it would stump Walter. Do you? He's already talking about
doing it for other things, and he's gonna' have to do something about
[length]. This seems largely irrelevant?



 Maybe even better to take __FILE__ and __DATE__ back out again, then.


Yep ~ we should all stick our heads into the sand :-)


Q: Would adding *both* work ? _file (newcomers) and __FILE__ (oldtimers)


 Why? It's far better to be consistent. Particularly so when the




opportunity

 is just sitting there. If you wish to discuss the pros and cons of
 consistency, then let's take it out of this thread.


 Nah, I'm just trying to meddle so we can get on with our lives...

 Sorta like how adding the "bool" alias put a truce to *that* war.



That would be great, Anders. And I'm with you regarding the '_' prefix as
long as the compiler makes it illegal elsewhere. If that doesn't happen,
then another approach is needed. The solutions are not difficult. Instead,
the whole thing appears to be encased in a tomb of petty politics.
Mar 14 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:


 Excellent! That's a far better solution than changing things to be fully
 deterministic :-)


:-)
Just went back to the fallback: "I'm with Stupid" = let's do like C did.


 Oh. I don't think it would stump Walter. Do you? He's already talking about
 doing it for other things, and he's gonna' have to do something about
 [length]. This seems largely irrelevant?


Nope, I don't think it's too much. Just seemed overkill for this one ?

But maybe it needs to be withdrawn, and then redone properly instead ?


 That would be great, Anders. And I'm with you regarding the '_' prefix as
 long as the compiler makes it illegal elsewhere. If that doesn't happen,
 then another approach is needed. The solutions are not difficult. Instead,
 the whole thing appears to be encased in a tomb of petty politics.


Let's leave it at that then, and see what happens and what Walter says.

Meanwhile, there's a GDC to be updated and I posted a few other patches?
I'm sure there will be other things too, but this was my week's D budget
;-)

--anders
Mar 14 2005
parent "Kris" <fu bar.com> writes:
Yep ~ I saw your patches. I hope they survive intact :-)


"Anders F Björklund" <afb algonet.se> wrote in message
news:d157ad$2qft$2 digitaldaemon.com...

 Kris wrote:


 Excellent! That's a far better solution than changing things to be fully
 deterministic :-)


 :-)
 Just went back to the fallback: "I'm with Stupid" = let's do like C did.


 Oh. I don't think it would stump Walter. Do you? He's already talking




about

 doing it for other things, and he's gonna' have to do something about
 [length]. This seems largely irrelevant?


 Nope, I don't think it's too much. Just seemed overkill for this one ?

 But maybe it needs to be withdrawn, and then redone properly instead ?


 That would be great, Anders. And I'm with you regarding the '_' prefix




as

 long as the compiler makes it illegal elsewhere. If that doesn't happen,
 then another approach is needed. The solutions are not difficult.




Instead,

 the whole thing appears to be encased in a tomb of petty politics.


 Let's leave it at that then, and see what happens and what Walter says.

 Meanwhile, there's a GDC to be updated and I posted a few other patches?
 I'm sure there will be other things too, but this was my week's D budget
 ;-)

 --anders
Mar 14 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d156p4$2qfl$1 digitaldaemon.com>, Kris says...

That would be great, Anders. And I'm with you regarding the '_' prefix as
long as the compiler makes it illegal elsewhere.


So what would the compiler do with interfaces to C libraries that have leading
underscore symbols?


Sean
Mar 14 2005
parent "Kris" <fu bar.com> writes:
Right. This is partly why the other prefixes were suggested; so that they
/can/ be enforced (at least, I thought so).

I don't think for one moment that Walter would agree to restrict the '_'
prefix.


"Sean Kelly" <sean f4.ca> wrote in message
news:d157fv$2r80$1 digitaldaemon.com...

 In article <d156p4$2qfl$1 digitaldaemon.com>, Kris says...

That would be great, Anders. And I'm with you regarding the '_' prefix as
long as the compiler makes it illegal elsewhere.


 So what would the compiler do with interfaces to C libraries that have


leading

 underscore symbols?


 Sean
Mar 14 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:


 Why not make give them all the single '_' prefix, and then reserve said
 prefix for compiler use only? That's what's being asked for. The compiler
 would have to enforce the illegality of '_' prefixing for everything other
 than the recognized tokens.


[...]

 Surely it's easier for a user to remember to use one single 'special' prefix
 rather than a range of them? ("hmmm, I use two underscores sometimes, one
 underscore other times, and no underscores some other times? And some
 trailing underscores sometimes?")


So how about doing this, then: (as a compromise)

1) Declare all identifiers starting with _ as *illegal* to use
    (reserved for implementing compiler and library internals)

Already, _arguments and _argptr are kinda bad identifiers to use.

2) Add a short new form, in addition to the legacy "macro" form:
    (__FILE__ -> _file, __DATE__ -> _date, and so on. Both valid)

For instance, "__FILE__" could be a (built-in) alias for "_file" ?
Deprecated, if need be. But it's familiar to several, including me.

     ****

I still hope that '$' could be renamed as '_length' then,
but maybe that is just me. I just find it to look... odd ?

Just as long as the undecorated length goes away, it's OK.
(i.e that it becomes "just another identifier" once again)

http://www.digitalmars.com/d/changelog.html#new0116:


 It represents the length of the array. This is a trial feature,
 if it works out then these will happen in sequential releases:
 
    1. length will become deprecated inside [].
    2. length will be removed as the implicitly declared length,
       and it will be just another identifier. 


Maybe that puts this issue at rest? I'll put myself to, now.

--anders
Mar 14 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Sat, 12 Mar 2005 07:45:12 +1100, Matthew wrote:


 "John Reimer" <brk_6502 yahoo.com> wrote in message 
 news:d0sdva$27g1$1 digitaldaemon.com...

 Derek Parnell wrote:


Of all the alternatives, this ones seems to be a better choice. 
It's definitely not perfect, but perfect is hard to come by.


Grammar correction: "Of all the alternatives, this one seems to be 
the best choice." :-P



 No it doesn't ;-)


 Ha! :-)


 
 Are we yet ready to agree that neither $ not _ not $length have survived 
 enough criticism to pass, and that therefore all should be deprecated, 


No.
  

 and we should, now, move on to more significant flaws in the language.


Yes.


 I say we all give Walter a hearty slap on the back for moving to the 
 try-it-out paradigm,


Absolutely!.


 and declare this first one a success (albeit that 
 it's a success in the negative).


No.
 
-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
12/03/2005 8:20:15 AM
Mar 11 2005
prev sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
To me, _ looks more like a placeholder for something unnamed. I've often 
played with the idea of using it for closures like:

	fptr = myfunc(_,15);

being equivalent to

	fptr = function(sometype a) { return myfunc(a,15); }

This has several advantages and allows to do thing that cannot be done 
with literal functions (like capturing dynamic values at the time of 
creation of the closure.

But probably the idea is too unclear to bring it up here. I just 
remembered it when seeing _



Ben Hinkle schrieb:

 I don't know if this has been already proposed but I was pondering the 
 "negative index" and the "missing index" proposals and it occurred to me 
 that a place-holder that would be (a) an identifier, (b) unobtrusive and (c) 
 unlikely to be used by a real coder is an underscore. I grepped phobos for 
 some examples of a[a.length] and replaced them with a[_] to get a feel for 
 how it would look. At one point Walter proposed making it an error to have 
 the "magic length identifier" shadow a symbol with the same name - and I 
 think that would catch any yahoo who actually wants to have symbols named _
 
 ./std/format.d: putstr(tmpbuf[n .. _]);
 ./std/math2.d: real result = coefficients[_ - 1];
 ./std/math2.d: if (s[_ - 1] == 'h')
 ./std/path.d:     return fullname[i .. _];
 ./std/path.d: return fullname[i .. _];
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
 ./std/path.d: fullname = fullname[0 .. _ - existing.length] ~ ext;
 ./std/path.d:    return d.length < path.length && path[d.length] == sep[0];
 ./std/path.d:  else if (p1[_ - 1] == '\\')
 ./std/path.d:      p = p1 ~ p2[1 .. _];
 ./std/path.d:     else if (p1[_ - 1] == '\\')
 ./std/path.d: else if (p1[_ - 1] == sep[0])
 ./std/path.d:   if (fnmatch(name[j .. _], pattern[pi + 1 .. _]))
 ./std/regexp.d: result ~= string[p .. _];
 [snip many more examples from phobos]
Mar 12 2005