March 14, 2005
> 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


March 14, 2005
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 :-)


March 14, 2005
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
March 14, 2005
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...
> 
> #!/usr/bin/perl
> @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
March 14, 2005
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
March 14, 2005
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


March 14, 2005
"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.


March 14, 2005
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:
> #  $ can now be used instead of length inside an array's [].
> 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
March 14, 2005
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
March 14, 2005
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