On Thu, 24 Mar 2011 16:04:25 +0100, Don wrote:

> piotrek wrote:
>> On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:
>> 
>>> On Mar 24, 11 19:00, sclytrack wrote:
>>>> == Quote from piotrek (starpit@tlen.pl)'s article
>>>>> On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:
>>>>>> D already has a long list of keywords, reserved words can't be used as identifiers, which can be annoying. "body" in particular is a common noun that programmers would gladly use as a variable name in physics simulation, astronomy, mechanics, games, health, etc. I think "body" can be removed from D with no harm, and with the benefit of allowing the name as identifier.
>>>>> yes, please
>>>>> body is also a html tag
>>>>> Cheers
>>>>> Piotrek
>>>> Copied the following line from the Vala (=mostly reference counted
>>>> language) web page.
>>>>
>>>> "It is possible to use a reserved keyword as identifier name by prefixing it with the @ character. This character is not part of the name. For example, you can name a method foreach by writing @foreach, even though this is a reserved Vala keyword."
>>>>
>>>> My body is hungry and starving.
>>>>
>>>>
>>>>
>>> How is this better than _body or body_?
>> 
>> I think "@" is a little bit nicer, but it doesn't change the situation at all . body (if possible) shouldn't be a keyword. Can anyone from the steering group state his opinion? :)
> 
> What's the steering group?

I think you belong there. :) Along with Walter, Andrei, Brad and Sean.
Of course support of  David, Steven, Lars and Jonathan and the
whole community is invaluable. :)

> I raised this exact topic before, with the title "my body is ugly" <g>. It's a very silly keyword. It's just a comment, really /*body*/.

What stops Walter from removing it? If it was me, the next dmd release would have one keyword less ;) (Forget for a while that I'm not familiar with the dmd code)

Cheers,
Piotrek

On Mar 24, 11 22:25, piotrek wrote:
> On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:
>
>> On Mar 24, 11 19:00, sclytrack wrote:
>>> == Quote from piotrek (starpit@tlen.pl)'s article
>>>> On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:
>>>>> D already has a long list of keywords, reserved words can't be used
>>>>> as identifiers, which can be annoying. "body" in particular is a
>>>>> common noun that programmers would gladly use as a variable name in
>>>>> physics simulation, astronomy, mechanics, games, health, etc. I think
>>>>> "body" can be removed from D with no harm, and with the benefit of
>>>>> allowing the name as identifier.
>>>> yes, please
>>>> body is also a html tag
>>>> Cheers
>>>> Piotrek
>>>
>>> Copied the following line from the Vala (=mostly reference counted
>>> language) web page.
>>>
>>> "It is possible to use a reserved keyword as identifier name by
>>> prefixing it with the @ character. This character is not part of the
>>> name. For example, you can name a method foreach by writing @foreach,
>>> even though this is a reserved Vala keyword."
>>>
>>> My body is hungry and starving.
>>>
>>>
>>>
>> How is this better than _body or body_?
>
> I think "@" is a little bit nicer, but it doesn't change the situation at all . body (if possible) shouldn't be a keyword.
> Can anyone from the steering group state his opinion? :)
>
> Cheers,
> Piotrek

I agree body shouldn't be a keyword.

The @body solution doesn't work in D because:
  1. @identifier is already reserved for user attributes (@safe, etc.)
  2. What does @keyword.stringof (name of the variable) return?
      if it returns "@keyword", then it is no different from using "_keyword"
      if it returns "keyword", you may break many string mixins.
  3. @keyword exists in C# because the CLI isn't bound to any language, so a keyword in C# may not be a keyword in other CLI languages, and that would be got used. D shouldn't have this problem.

------

Speaking of which, how do we do

    extern(C) void body();

?

On Fri, 25 Mar 2011 00:50:56 +0800, KennyTM~ wrote:

> On Mar 24, 11 22:25, piotrek wrote:
>> On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:
>>
>>> On Mar 24, 11 19:00, sclytrack wrote:
>>>> == Quote from piotrek (starpit@tlen.pl)'s article
>>>>> On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:
>>>>>> D already has a long list of keywords, reserved words can't be used as identifiers, which can be annoying. "body" in particular is a common noun that programmers would gladly use as a variable name in physics simulation, astronomy, mechanics, games, health, etc. I think "body" can be removed from D with no harm, and with the benefit of allowing the name as identifier.
>>>>> yes, please
>>>>> body is also a html tag
>>>>> Cheers
>>>>> Piotrek
>>>>
>>>> Copied the following line from the Vala (=mostly reference counted
>>>> language) web page.
>>>>
>>>> "It is possible to use a reserved keyword as identifier name by prefixing it with the @ character. This character is not part of the name. For example, you can name a method foreach by writing @foreach, even though this is a reserved Vala keyword."
>>>>
>>>> My body is hungry and starving.
>>>>
>>>>
>>>>
>>> How is this better than _body or body_?
>>
>> I think "@" is a little bit nicer, but it doesn't change the situation at all . body (if possible) shouldn't be a keyword. Can anyone from the steering group state his opinion? :)
>>
>> Cheers,
>> Piotrek
> 
> I agree body shouldn't be a keyword.
> 
> The @body solution doesn't work in D because:
> ...

Yes I know. I was only referring to how it looks.
I'm allergic to the underscore char in programming languages ;)
"better" in my previous post was like:
2 cents are "better" than 1 cent and I can have 1 million dollars.
So why would I want "@body" if I can have "body".
@body was just useless noise.

Cheers,
Piotrek

On Wed, 23 Mar 2011 18:17:32 -0400, Alvaro <alvaroDotSegura@gmail.com> wrote:

> D already has a long list of keywords, reserved words can't be used as identifiers, which can be annoying. "body" in particular is a common noun that programmers would gladly use as a variable name in physics simulation, astronomy, mechanics, games, health, etc. I think "body" can be removed from D with no harm, and with the benefit of allowing the name as identifier.
>
> Rationale: Functions in C and derived languages have always had a body and they never needed a keyword. In D, "body" is used to mark the actual body of a function after the optional "in" and/or "out" contract blocks. What is different in the body itself of a function with and without contracts to make one body{...} and the other {...}?
>
> Example:
>
> int myfunc(int x)
> in{
>      ...contract preconditions...
> }
> out (result){
>      ...contract postconditions...
> }
> body{
>      ...code...
> }
>
> But we don't write:
>
> int myfunc(int x)
> body{
>      ...code...
> }
>
> The body keyword can be omitted and still interpret the code correctly given this rule: "An unnamed {...} block right after an in{} or out{} block when defining a function, MUST be the function's body". Thus, the above code would become:
>
> int myfunc(int x)
> in{
>      ...contract preconditions...
> }
> out (result){
>      ...contract postconditions...
> }
> {
>      ...code...
> }
>
> and be perfectly understandable, with the benefit of one less keyword. The compiler, upon reading the opening "{" after the out block, would know it is the beginning of the function body.
>
> Or I am missing something that would overcomplicate parsing, etc?

Most likely it's not necessary.

But I don't know that it's so terrible to have it as a keyword.  Clearly there was a "free keyword love" period in D's past, but I think it takes a lot more than just "we could technically do this without a keyword" to remove it from the language.  For one, it would break tons of existing code.

I wouldn't mind it becoming a contextual keyword (like C#'s get and set inside properties).

One thing it does help with is it provides a visual (and searchable) anchor for a person reading a function.  For example if preconditions and postconditions come before the body and are quite long, being able to do /body in vi is nice.  It also would seem like something was missing if it was just blank (of course, only when the in/out contracts are there).

-Steve

"Sönke Ludwig" <ludwig@informatik.uni-luebeck.de> wrote in message news:imeqnd$12ss$1@digitalmars.com...
> I'm all for this change.
>
> Since there are already similar differences between 1.0 and 2.0 (e.g. invariant()) and projects can be fixed by a more or less simple search and replace, this would be a cheap way to clean up a keyword that can truly get in your way (in contrast to some others that have already been removed).
>
> Actually I think the only keywords that really got in my way were "body" and "function" - I now have modules named body_.d and function_.d

I've had "unittest", "mixin" and "in" get in the way (but not in any way that was actualy a real problem, just a minor *minor* inconvenience).

I definitely had "in" as a problem. Its because some people like to use that in C code. (Qt being the most recent example).

I've also had issues with "string". That one can be common in C code. Its a pretty bad habit of naming your variables for what type they are instead of their purpose. I guess it fits into that whole "I'll hack it just for now, and fix it never" mentality.

> I definitely had "in" as a problem. Its because some people like to use that in C code. (Qt being the most recent example).
> 
> I've also had issues with "string". That one can be common in C code. Its a pretty bad habit of naming your variables for what type they are instead of their purpose. I guess it fits into that whole "I'll hack it just for now, and fix it never" mentality.

_Any_ keyword can conflict with a variable name. Some - like const - aren't terribly likely to be names that a programmer will want to use for a variable, but most of them are. Well-selected keywords do a good job of describing what they're for - just like well-selected variable names. So, there's going to be some overlap between good keywords and good variable names. Such is life with pretty much any programming language. And taking code in one programming language with a certain set of keywords and porting it to another with a different set of keywords is bound to run into trouble from time to time.

Now, string is pretty bad on the whole, but then again, there are plenty of cases where you just don't care about what a string is for and str or string makes perfect sense (a prime example would be functions which operate on general strings - such as std.string). IIRC, there are parameters in std.array called array, simply because you don't care what the array is for. The fact that it's an array is all that matters.

Regardless, no matter what keywords a language picks, they'll conflict with variable names that programmers want to use unless they're complete gibberish such as aesnth or rcoevw, and such keywords would be _horrible_.

- Jonathan M Davis

On 3/24/11, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Now, string is pretty bad on the whole, but then again, there are plenty of cases where you just don't care about what a string is for.

You don't care now, but you'll care later when its time to fix a bug.
Sometimes, its obvious what a name is by looking at the function call,
e.g.:
arr = getArrayOfInts();

But if this call is buried somewhere in the midst of spaghetti code inside another function, and arr is used 100 lines below, by the time you see it again you'll forget what it is for or what it contains.

Small functions that have these kinds of names are okay. Its the long ones that are the problem. And the long ones usually have a multitude of names like that. So you end up reading code written like this:

arr1 += arr3 * j / k;

Saves you a few seconds while writing, but makes you lose a lot of time when trying to understand this code a few months down the road.

On 2011-03-24 16:23:40, Andrej Mitrovic wrote:
> On 3/24/11, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > Now, string is pretty bad on the whole, but then again, there are plenty of cases where you just don't care about what a string is for.
> 
> You don't care now, but you'll care later when its time to fix a bug.
> Sometimes, its obvious what a name is by looking at the function call,
> e.g.:
> arr = getArrayOfInts();
> 
> But if this call is buried somewhere in the midst of spaghetti code inside another function, and arr is used 100 lines below, by the time you see it again you'll forget what it is for or what it contains.
> 
> Small functions that have these kinds of names are okay. Its the long ones that are the problem. And the long ones usually have a multitude of names like that. So you end up reading code written like this:
> 
> arr1 += arr3 * j / k;
> 
> Saves you a few seconds while writing, but makes you lose a lot of time when trying to understand this code a few months down the road.

You don't care when it doesn't matter one whit what the variable is for - only what its type is. Take one of the signatures for std.array.insert for example:

void insert(T, Range)(ref T[] array, size_t pos, Range stuff)
if (isInputRange!Range && is(ElementEncodingType!Range : T))


The array is called array. This is because that's all you care about. It's the array that you're processing. The whole point of the function is to insert into an array. So, the fact that it is an array is what is important. There arguably isn't a better name. The length of the function is irrelevant.

Most functions, on the other hand, are trying to do something with much more semantic meaning to it and _do_ care about what is in the variable. In _those_ functions, names like array or string are horrible. You want names which actually indicate what the variable is _for_.

So, in most cases, I would agree with you that variable names like array are horrible. However, there _are_ certain types of functions where you _can't_ really give a better name, because the type of the variable is _all_ that matters. That's why you have std.array functions with a parameter called array or std.range functions with a parameter called range or r. What the variable is _for_ is irrelevant at that point. You just don't care. All that matters is what type is. But that is not the norm for variable names by any means.

- Jonathan M Davis

On 2011-03-24 16:23:40, Andrej Mitrovic wrote:
> On 3/24/11, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > Now, string is pretty bad on the whole, but then again, there are plenty of cases where you just don't care about what a string is for.
> 
> You don't care now, but you'll care later when its time to fix a bug.
> Sometimes, its obvious what a name is by looking at the function call,
> e.g.:
> arr = getArrayOfInts();
> 
> But if this call is buried somewhere in the midst of spaghetti code inside another function, and arr is used 100 lines below, by the time you see it again you'll forget what it is for or what it contains.
> 
> Small functions that have these kinds of names are okay. Its the long ones that are the problem. And the long ones usually have a multitude of names like that. So you end up reading code written like this:
> 
> arr1 += arr3 * j / k;
> 
> Saves you a few seconds while writing, but makes you lose a lot of time when trying to understand this code a few months down the road.

You don't care when it doesn't matter one whit what the variable is for - only what its type is. Take one of the signatures for std.array.insert for example:

void insert(T, Range)(ref T[] array, size_t pos, Range stuff)
if (isInputRange!Range && is(ElementEncodingType!Range : T))


The array is called array. This is because that's all you care about. It's the array that you're processing. The whole point of the function is to insert into an array. So, the fact that it is an array is what is important. There arguably isn't a better name. The length of the function is irrelevant.

Most functions, on the other hand, are trying to do something with much more semantic meaning to it and _do_ care about what is in the variable. In _those_ functions, names like array or string are horrible. You want names which actually indicate what the variable is _for_.

So, in most cases, I would agree with you that variable names like array are horrible. However, there _are_ certain types of functions where you _can't_ really give a better name, because the type of the variable is _all_ that matters. That's why you have std.array functions with a parameter called array or std.range functions with a parameter called range or r. What the variable is _for_ is irrelevant at that point. You just don't care. All that matters is what type is. But that is not the norm for variable names by any means.

- Jonathan M Davis