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

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


March 14, 2005
> I keep getting confused...are we trying to create the D language or a variety of C?

yes


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



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