Hi,

>> The examples there contradict yours. I don't have a compiler at hand, though, so I can't say. I prefer what the docs say, frankly.
>
>Yes, I knew about the docs, but I believe Walter has said that the docs are wrong in this case. The compiler does compile the examples I gave and this is the intended behaviour. I just can't find the Walter-quote right now.

Hm... interesting. I hope Walter brings back the behaviour in the docs.

>Yes, I can understand this. We have defined coding standards here and all code is peer-reviewed and non-standard code is identified and corrected before being allowed to go out into the world. But under more common development methodologies, I can understand that you'd like to have a mechanized method of enforcing coding decency - i.e. the compiler.

Exactly! Thank you. I'm glad somebody here understands.

>> <often quoted possibly completely wrong statistic>
>> <take this with a grain of salt>
>> Around 80% of the total cost of software is not the original development.
>> </take this with a grain of salt>
>> </often quoted possibly completely wrong statistic>
>
>I think I heard once that 94.37% of all statistics are misused, and the remaining 84.12% are actually a bit suspect too.

"There are three types of lies - lies, damn lies, and documentation."

Hehehe...
--AJG.

On Fri, 5 Aug 2005 13:45:14 +0000 (UTC), AJG wrote:


[snip]

>>Yes, I can understand this. We have defined coding standards here and all code is peer-reviewed and non-standard code is identified and corrected before being allowed to go out into the world. But under more common development methodologies, I can understand that you'd like to have a mechanized method of enforcing coding decency - i.e. the compiler.
> 
> Exactly! Thank you. I'm glad somebody here understands.

But the problem is that we are then stuck with somebody else's interpretation of what decency is (i.e. the language designer) and we don't have the freedom to use another interpretation. A general purpose language should be just that - general purpose. Inserting artificial restrictions that are only there to support a specific coding philosophy is fine - just don't call it a general purpose language in that case.

I actually support the idea of reducing the number of keywords in D. The current built-in types really shouldn't be keywords. And they are inconsistent ... 'Object' is not a keyword, 'bool' is not a keyword.

void main()
{
  int Object = 2; // okay
  int bool = 3; // okay
  int real = 4; // error
}

The other keywords in the language are punctuation symbols that the compiler uses, and this is the reasonable use for keywords.

-- 
Derek Parnell
Melbourne, Australia
6/08/2005 6:01:37 AM

Hi,

>Yes, you can construct cases where there is confusion. This does not change the fact that there are useful implications.

The minimal useful "implications" are overshadowed. Moreover, even these implications can be achieved thru far simpler, far cheaper solutions: Either the quotes proposal, or a simple global search and replace.

>> In addition, the feature has _very_ _little_ _benefit_. In other words, it is not worth introducing the great potential for confusion for such a miniscule gain in functionality. The juice is not worth the squeeze.
>
>We'll have to agree to differ on that. I keep bringing up C++, not because I'm confusing D with C++, but because, more than once, I've been bitten by C++ adding new keywords (either relative to C, or to its own former self).

Yes, we'll have to differ. I haven't once run into a single keyword collision, in any language I've used. Maybe I've just been lucky. :p

>> what is he supposed to think? It kinda looks like "use this version if D is compiled with real number support." Or perhaps "use this version if you want real number precision."
>> 
>Or you could read the manual. The relevant page is a google and about 3 clicks away :-). I had no idea at all how 'version' worked until I read the manual.

The more intuitive you make things, the better overall. That's just commonsense.

>>>And again, it's not the existing keywords that are the issue, it's the new ones that will be defined later.
>> 
>> 
>> Frankly, I don't see a flood of new primitive types and keywords. I'd speculate maybe a couple per year, since Walter likes to reuse his keywords. That's just a risk you're gonna have to take. Btw, perhaps you shouldn't be naming your things so close to already existing keywords.
>
>I had trouble with C++, at a much lower rate of keyword growth.

When you say you "had" trouble, does this mean:
"Well, there was this one time where one identifier collided with a keyword;"
or
"Heck, I ran into keywords left and right. It seemed the very language evolved
against my code!"

>> There's char, there's dchar, there's wchar. It doesn't take a genius to figure out the naming convention here. Therefore it also doesn't take a genius to figure out that rchar is particularly prone. Also, here's another quick tip: keywords in D are all lowercase. Hint, hint.
>> 
>Right. But the problems I had with C++ were with code others had written. If you have full control over all of the code you work with, none of this matters nearly as much. Lucky you.

As a matter of fact I don't. Despite this fact it's never been a problem.

>I don't intend to stop using local variable names consisting entirely of lowercase letters. And, the set of likely new type names is (a) not quite as predictable as that and (b) not utterly disjoint from the set of likely names for local vars, parameter names, and member names, all of which are lowercase by many coding conventions.

In D, it's actually predictable to a certain degree:
stmt is unlikely to become a keyword.
statement could.
expr, wouldn't.
expression, could.

* The one exception I can think of is "const" which I believe was kept due to C. Had walter had his choice, I think he would have gone with "constant."

Verbs/prepositions: in/do/is/for/a/as/be.
Things like: while/when/where/what/why.

Moreover, if you are talking about _types_, it is a good naming convention to
capitalize those (and keywords are all lowercase):
Database;
Statement;
Result;

I think following those simple conventions almost guarantees not running into a keyword. Language designers (D included) are not stupid. "i" and "j" won't become keywords.

>flawed premise, see above. The main point is, if you are redefining the new built-in type 'rchar', you are doing it because it wasn't there when you wrote the code. So, you want the new 'rchar' type to be hidden in all places where the user's 'rchar' is in scope. Which is what the existing scope rules do already.

AND

>I think you are mistaken, or just being evasive. I remember seeing something about how a D local isn't allowed to hide a local in an enclosing scope,which is fine; but a local variable *can* hide a global. I just tried it.

I'm sorry about this. I'm confused ATM about scopes/identifiers because apparently the D docs say one thing and Walter "said" another. I'm not sure what I'm supposed to conclude.

>I agree there is a risk of a global namespace being affected by modifications to the local namespace, but the effect of that is contained to the locality of the change, so it's reasonable to expect that to be addressed by diligence (and via variable naming conventions).

The "containment" you speak of is very leaky. Throughout the code that redefines rchar, the original rchar would be subtly hidden. So if a programmer with no knowledge of this comes along (since, as you said, you are not the only one involved), and uses rchar, then there will be trouble.

Whereas as it stands, simple knowledge of D itself (not of whatever "variations" the specific code imposes) is enough to understand unambiguously what (the hypothetical) rchar is. IMHO it is a much safer assumption to think a programmer will know the language itself before whatever else is written with it.

>> No. You seem to ignore the costs of your little operation: it would probably take valuable time to implement. It would require complex scoping rules to be created. In addition to the potential for abuse.
> >
>IMHO not as bad as you think, and will never be any easier to implement than now. D already has a bunch of predefined identifiers (Object, max, nan, infinity, sizeof...) - does that bother you?

No, because right now I couldn't accidentally redefine those to hide the real ones. For instance, "real.max" will always be real.max, not some user defined thing.

>>>If you want it to be illegal to redefine int, you can *still* make int a predefined identifier, not a keyword, and make it illegal to redefine it, in whatever contexts you think it might be harmful, including all of them. I'm not going to repeat all the reasons why this is different from int being a keyword, you can go check out the other thread "Why are type names keywords".
>> 
>> 
>> So then you need to introduce complex scoping rules for predefined identifiers just so you can use language keywords in certain special scopes were they are not meaningful. Does this makes sense over a simple "no use" rule across the language?
> >
>The existing scope rules are fine. The 'no use' rule has the problems I have mentioned, it's not future-proof.

Are you saying the variable scoping rules could be applied _identically_ to type redefinition? That would yield some interesting results.

Moreover, the language will _never_ be future-proof. If you name your type something that becomes a non-type keyword, you are skunked too my friend.

>>>If you insist on using 'int' as an example and fail to recognize that the language has both a past (C code compatiblity)
>> 
>> 
>> D does not have C code compatibility. It would be hazardous to your mental health to keep believing that. If you fail to recognize that then you should work on it.
>
>You can link to external C code. This is what I meant.

You can't "link" to code. You link to objects, which are no longer code. Once again, D does not have C code compatibility. I don't know why you keep bringing this up. D has C library _link_ compatibility, which is quite a different beast.


Most languages can link to C too. D's syntax being _similar_ to C has little relevance in this respect.

>This compatibility is degraded by having too many keywords.

Furthermore, clearly the definition of "too many" is quite subjective and relative. If you want to see some languages with truly "too many" keywords, then I can show you plenty.

>>>>>This suggestion is separate from the suggestion that type names should not be keywords; either could be adopted without the other.
>>>>
>>>>This makes a _lot_ more sense than allowing people to name their functions "delegate". You should push for this suggestion instead.
>>>>
>>>Actually, I *am* exactly proposing that people be allowed to name their functions "delegate". I'm just proposing a method of doing it despite the presence of a keyword "delegate". Note that
>>>   foo()  and 'foo'()
>>>...would be identical.
>> 
>> 
>> Well, no they wouldn't (if foo were a keyword), because you'd have to always use quotes to accesss foo. In other words, it's almost as if the quotes became part of the identifier and they were taken off only for C-compat.
>> 
>I'm just saying that by declaring " int 'delegate'(), you are naming a function "delegate", plain and simple. You said 'this makes more sense than allowing people to name their functions "delegate"' . I found that statement very confusing and hoped to clarify things. I see now what you were getting at; but I have never proposed removal of any keywords other than those which are manifestly unnecessary for parsing; 'delegate' isn't in that list.

Then why did your example have delegate expressly in it??? Now who's being evasive? ;)

>>>>Allowing redefinition of "this" is insane IMO.
>>>>
>>>
>>>I agree that it's no huge improvement. 'Insane', no. In fact, 'this' in
>>>C++ (not D) is a perfect example of something that doesn't need to be a
>>>keyword.
>>>It is *only* meaningful in contexts where a member function parameter
>>>has scope, and has exactly the same grammar treatment as an identifier.
>>>Nothing is gained by making it a keyword.
>>>In D the 'this' keyword is doing more work, in constructor declarations,
>>>etc, so the situation is different.
>> 
>> Unfortunately, D is not C++ and in D, this has almost universal meaning. In fact, at the base scope (module-level, I assume), 'this' is relevant, due to static ctors/dtors.
>> 
>> My suggestion that redefining 'this' is insane applies to D, not C++, or I would have said so. Since apparently you didn't like my redefining int that much, let me propose redefining this then ;)
>
>well that caused me a lot of confusion since I explicitly said I was talking about removing keyword 'this' in C++ and not D. The parallel is that 'wchar' in D, like 'this' in C++, and 'Object' in D, doesn't actually need to be a keyword. Of these three, only 'Object' has the benefit of being a predefined identifier rather than a keyword.

Mostly because Object is not a primitive. That's a big difference.

>>>>>But if you had some  old C code that defined a struct member 'this', you wouldn't have to change that to convert it into our mutant C++, whereas with real C++, you do.
>>>>
>>>>
>>>>What about the simple suggestion to allow quoted identifiers?
>>>>
>>>>extern (C) 'this'(int foo); // for a function called 'this'.
>>>>
>>>
>>>I was discussing converting old C source code into C++, not linking old C code to D. If C++ 'this' were *not* a keyword, I wouldn't need to change any 'this' identifiers in the C code, since none of them could conflict with the C++ meaning.
>> 
>> 
>> If you are converting old C code to D chances are you are already doing some heavy lifting.
>Again, I'm not talking about converting C to D; I'm talking about the general effects of adding new keywords.

You keep going back and forth using C code as a point and then saying you are not "talking about" it. But you _were_ talking about C code just there. Also, I'm sure converting C code to COBOL would pose some difficulties, and I'm sure adding new keywords to COBOL has its own set of problems, but I wouldn't bring it up as proof of my point.

>The task of converting C source to C++ is just a real world example of where these effects show up. They
>  will also show up if/when new keywords are added to D.

If the conversion is going to take place, then you are back to what I said about the "heavy lifting." You can't have your cake and eat it. Are you going to convert code to D or not?

Cheers,
--AJG.

Hi,

>>>Yes, I can understand this. We have defined coding standards here and all code is peer-reviewed and non-standard code is identified and corrected before being allowed to go out into the world. But under more common development methodologies, I can understand that you'd like to have a mechanized method of enforcing coding decency - i.e. the compiler.
>> 
>> Exactly! Thank you. I'm glad somebody here understands.
>
>But the problem is that we are then stuck with somebody else's interpretation of what decency is (i.e. the language designer) and we don't have the freedom to use another interpretation. A general purpose language should be just that - general purpose. Inserting artificial restrictions that are only there to support a specific coding philosophy is fine - just don't call it a general purpose language in that case.

_Some_ decency is better than _no_ decency. The "interpretations" are generally linear in that there is usually "more" and "less." I'll always want more. And of course, I wouldn't want the "zero" interpretation.

>And they are
>inconsistent ... 'Object' is not a keyword, 'bool' is not a keyword.

Hey, that inconsistency is a problem by itself. I'd treat it as a bug.

>I actually support the idea of reducing the number of keywords in D. The other keywords in the language are punctuation symbols that the compiler uses, and this is the reasonable use for keywords.

Ceteris paribus, I also support the idea of less keywords. But not when it reduces the "decency," if you will, and also not when it leads the syntax to become like Perl's.

Cheers,
--AJG.

AJG wrote:

>>>>And again, it's not the existing keywords that are the issue, it's the new ones that will be defined later.
>>>
>>>
>>>Frankly, I don't see a flood of new primitive types and keywords. I'd speculate
>>>maybe a couple per year, since Walter likes to reuse his keywords. That's just a
>>>risk you're gonna have to take. Btw, perhaps you shouldn't be naming your things
>>>so close to already existing keywords.
>>
>>I had trouble with C++, at a much lower rate of keyword growth.
> 
> 
> When you say you "had" trouble, does this mean:
> "Well, there was this one time where one identifier collided with a keyword;"
> or
> "Heck, I ran into keywords left and right. It seemed the very language evolved
> against my code!"
> 
One time it was more than one. But it makes no difference; what matters is the difference between "I have these 10K lines of code which work, out of the box" and "I have to spend a bunch of time changing things, and now I possibly have to maintain a local mod of 3rd-partty source, because the other guys prefer to use the old compiler which I can't use for some other reason". The maintenance issue can easily overshadow the effort of making the change.

> 
> 
> The "containment" you speak of is very leaky. Throughout the code that redefines
> rchar, the original rchar would be subtly hidden. So if a programmer with no
> knowledge of this comes along (since, as you said, you are not the only one
> involved), and uses rchar, then there will be trouble.
> 
Yes. But this difficulty is only encountered when you change the code, not when you upgrade the compiler; and it's local to the change. I prefer it to the other difficulty.
> 
> No, because right now I couldn't accidentally redefine those to hide the real
> ones. For instance, "real.max" will always be real.max, not some user defined
> thing.
> 
What does a.max mean? 'a' could be from 'alias int a', or a class object. My point is, the required scoping rules are clearly already in place.
>>>So then you need to introduce complex scoping rules for predefined identifiers
>>>just so you can use language keywords in certain special scopes were they are
>>>not meaningful. Does this makes sense over a simple "no use" rule across the
>>>language?
>>>
>>
>>The existing scope rules are fine. The 'no use' rule has the problems I have mentioned, it's not future-proof.
> 
> 
> Are you saying the variable scoping rules could be applied _identically_ to type
> redefinition? That would yield some interesting results.

The scoping rules already apply to types! every time you define an alias, or a typedef, or a class, or you import a type from a module, you are making some identifier refer to a type. There are scoping rules for that.

> 
> Moreover, the language will _never_ be future-proof. If you name your type
> something that becomes a non-type keyword, you are skunked too my friend.
> 
The point is to reduce the probability. New type names are more likely than other kinds of keywords. There are a lot of specialized C compilers  (for DSPs, etc) which define special types for the environment; the same  may happen to D; the new types should be p.d. indentifiers, not kwords,  and this will be easier if the existing ones are too.

>>You can link to external C code. This is what I meant.
> 
> 
> You can't "link" to code. You link to objects, which are no longer code. Once
> again, D does not have C code compatibility. I don't know why you keep bringing
> this up. D has C library _link_ compatibility, which is quite a different beast.
> 
> 
> Most languages can link to C too. D's syntax being _similar_ to C has little
> relevance in this respect.
> 
??
If I write "int is_it_prime(int n);" in C, and leave it in a .c file, then I can write "extern (C) int is_it_prime( int n);" in D, and  link them together and call the func from D. No? That's what I mean by 'linking to external C code'. I use the linker. The external code is in C. The linker obviously cannot process C source, so yes, it needs to be compiled, but it's still 'C code' due to its origins.  I know how things like this can be confusing; when I first read your 'You link to objects', I thought you meant 'class' objects rather than .o files, and was temporarily baffled. But I took the time to understand what you actually meant. I've been linking object modules (not objects) using linkers since about 1980, so please try to give me the benefit of the doubt for any confusing phraseology.

>>I'm just saying that by declaring " int 'delegate'(), you are naming a function "delegate", plain and simple. You said 'this makes more sense than allowing people to name their functions "delegate"' . I found that statement very confusing and hoped to clarify things. I see now what you were getting at; but I have never proposed removal of any keywords other than those which are manifestly unnecessary for parsing; 'delegate' isn't in that list.
> 
> 
> Then why did your example have delegate expressly in it??? Now who's being
> evasive? ;)
> 
Why? Exactly for that reason! I was trying to avoid confusion (ha!). Stay with me here. I didn't want to use a type name in the example, since I've proposed that they *not* be keywords, and I wanted it to be very clear that the word used in the example was definitely a keyword, hopefully avoiding any confusion with the other proposal. Also, 'delegate' seems fairly prone to a collision with a C function in some weird library.
>
> 
> Mostly because Object is not a primitive. That's a big difference.
>
Sure, but I don't see it as that big that it needs to impact the grammar. They're all built-in types.

>>
>>Again, I'm not talking about converting C to D; I'm talking about the general effects of adding new keywords. 
> 
> 
> You keep going back and forth using C code as a point and then saying you are
> not "talking about" it. But you _were_ talking about C code just there. Also,
> I'm sure converting C code to COBOL would pose some difficulties, and I'm sure
> adding new keywords to COBOL has its own set of problems, but I wouldn't bring
> it up as proof of my point.
>
You are getting very close by bringing up COBOL. If I had an example of how an unnecessary keyword could be easily removed from the Arcturian language Zlatwold-II, without degrading it in any way, and how that would make converting code from the similar language Zlatwold-I (*not* C) easier, and if everybody knew the languages enough to make sense of the example, then maybe I would have used that example to illustrate my point. I've used C/C++ instead of Zlatwold-I/II. Any similarity between C/C++ and D is not relevant. I'm not talking about *converting* *C* *code* *to* *D*, but I was, as you say, talking about C. I don't see any "going back and forth" there. The relevance is to when you have to someday convert D-I to D-II, and D-II may have additional, unnecessary, keywords.


> If the conversion is going to take place, then you are back to what I said about
> the "heavy lifting." You can't have your cake and eat it. Are you going to
> convert code to D or not?
>
Why is this relevant??? The only relationship between C and D i've discussed is via the extern(C) linking process.

-Greg