www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "body" keyword is unnecessary

reply Alvaro <alvaroDotSegura gmail.com> writes:
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?

Best regards
Mar 23 2011
next sibling parent Trass3r <un known.com> writes:
Yep, this has been brought up at least once before.
Nothing has happened so far.
Mar 23 2011
prev sibling next sibling parent reply Bekenn <leaveme alone.com> writes:
Interestingly, you don't even have to remove "body" from the syntax to 
remove it as a keyword, as it's only used in this context (that I know 
of), where no other symbols make sense.
Mar 24 2011
parent Ary Manzana <ary esperanto.org.ar> writes:
On 3/24/11 4:02 AM, Bekenn wrote:
 Interestingly, you don't even have to remove "body" from the syntax to
 remove it as a keyword, as it's only used in this context (that I know
 of), where no other symbols make sense.

And oh so many keywords could be removed from the language if the compiler is smarter... I was really amazed when I found out public, protected and private are methods in Ruby, not keywords. In fact, I don't know if a concept like keyword exists in Ruby... and this is soooo good... I use the name "body" for an HTTP response. At all times, every compiler writer should take this into account: "When we discovered Ruby, we realized that we’d found what we’d been looking for. More than any other language with which we have worked, Ruby stays out of your way. You can concentrate on solving the problem at hand, instead of struggling with compiler and language issues. That’s how it can help you become a better programmer: by giving you the chance to spend your time creating solutions for your users, not for the compiler.”
Mar 24 2011
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <ludwig informatik.uni-luebeck.de> writes:
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
Mar 24 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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).
Mar 24 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 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
Mar 24 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Mar 24 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Mar 24 2011
prev sibling next sibling parent reply piotrek <starpit tlen.pl> writes:
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
Mar 24 2011
next sibling parent reply sclytrack <sclytrack superidiot.com> writes:
== 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.

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.
Mar 24 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
sclytrack:

 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."

In C# there is the same thing:
The prefix " " enables the use of keywords as identifiers, which is useful when
interfacing with other programming languages. The character   is not actually
part of the identifier, so the identifier might be seen in other languages as a
normal identifier, without the prefix. An identifier with an   prefix is called
a verbatim identifier. Use of the   prefix for identifiers that are not
keywords is permitted, but strongly discouraged as a matter of style.<

http://msdn.microsoft.com/en-us/library/aa664670%28v=vs.71%29.aspx Bye, bearophile
Mar 24 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
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.

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_?
Mar 24 2011
next sibling parent reply Don <nospam nospam.com> writes:
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.

body is also a html tag Cheers Piotrek

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.


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 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*/.
Mar 24 2011
parent reply Don <nospam nospam.com> writes:
piotrek wrote:
 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.

body is also a html tag Cheers Piotrek

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.


at all . body (if possible) shouldn't be a keyword. Can anyone from the steering group state his opinion? :)


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. :)

Walter makes all the language decisions. The rest of us have just been able to convince him on multiple occasions (but I think that even Andrei has not achieved 50% convince rate). Hint #1: if you want to convince Walter, produce some real world use cases. Hint #2: you've got more chance if you make a patch, but ONLY if you've satisfied hint 1.
 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)

Priorities. If you spend any time on 'body', that's time taken away from fixing important bugs. The potential benefit is *tiny*. There are 1000 bugs that are more important.
Mar 25 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/25/2011 2:09 AM, Don wrote:
 Walter makes all the language decisions. The rest of us have just been able to
 convince him on multiple occasions (but I think that even Andrei has not
 achieved 50% convince rate). Hint #1: if you want to convince Walter, produce
 some real world use cases. Hint #2: you've got more chance if you make a patch,
 but ONLY if you've satisfied hint 1.

Nobody would like it if I was easy to convince. There are multiple language change suggestions here *every day*. Day after day, that adds up to a frightening number. To make a language change stick, it has to have a large benefit divided by its cost. Costs for even small changes can be huge - implementation, testing, documentation, tutorials, books, existing code base, distraction from other issues, instability, regressions, etc.
 Priorities. If you spend any time on 'body', that's time taken away from fixing
 important bugs. The potential benefit is *tiny*. There are 1000 bugs that are
 more important.

Right. I'm currently working on the temp destruction problem. While not sexy or even particularly visible, it not working right has serious deleterious consequences.
Mar 25 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/25/2011 2:40 PM, piotrek wrote:
 I really appreciate Walter's work and didn't want
 to make any pressure on him (like I could ;). I'm grateful for him for all
 amazing staff he did. D is the most beautiful language I have seen. It
 has its pitfalls, but we know there can't be any perfect one. For now we
 can live with our "body" :)

Thanks for the kind words. Not everyone thinks that way http://www.reddit.com/r/programming/comments/gacna/bye_bye_nullpointerexceptions/c1m3r7n :-)
Mar 25 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 Thanks for the kind words. Not everyone thinks that way
 
 http://www.reddit.com/r/programming/comments/gacna/bye_bye_nullpointerexceptions/c1m3r7n
 
 :-)

I didn't see that thread, thank you for the link. Some of your answers shown in that Reddit page were really wrong (like that "null pointer exception is reinvented"), I hope you know better now. About the notnulls topic, I have expressed my point of view some times, I think a notnull suffix syntax for pointers/object references, plus a bit of type state semantics are able to avoid most problems caused by nulls. Regarding your "dynamite general case solution", that probably Andrei too was referring with "working on a disable property that will allow non-null types to be implemented as a library-defined type constructor." I remember some people in this newsgroup appreciating the idea, but I didn't understand it much. Null-derived bugs are indeed only one special case of bugs that are avoided in languages like Haskell, and by good typestate-based languages, so a more general solution for them all will be good. But on the other hand there is the risk of over-generalization: null-caused bugs are the most common in that class of related bugs, so maybe a solution that's focused only on null-related bugs can be better and simpler, both syntax-wise and regarding how much handy it is to use *everywhere* (because you want to use it everywhere in OOP programs and even on programs that use pointers. My suggestion was about notnullable raw pointers too). So I will wait for a more defined explanation of this disable idea, to comment some more. Bye, bearophile
Mar 25 2011
prev sibling parent reply Alvaro <alvaroDotSegura gmail.com> writes:
El 25/03/2011 22:40, piotrek escribió:

 Speaking of real world examples(is my world really real? :D)
 I hit "body" when I was doing an html generator. Long before that when
 I was reading language specification I looked with distaste at the "body"
 keyword in the contract programming section. Still no big deal.

A bit off-topic post: I first hit "body" when porting the nbody benchmark test from the Computer Language Shootout to D. http://shootout.alioth.debian.org/u32/performance.php?test=nbody#about I wanted to write things like: foreach (ref body; bodies) { body.x += dt * body.vx; body.y += dt * body.vy; body.z += dt * body.vz; } BTW, in that benchmark D, with my clean implementation, would perform similar to "Clean", about 1.7x slower than the fastest, Fortran. That is with GDC and all optimizations. DMD a bit behind with a 2.1x elapsed time. Both are behind Java, C and C++.
Mar 26 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Alvaro:

 A bit off-topic post:

It's not off-topic, you have shown one case where the keyword "body" is useful as variable name.
 I first hit "body" when porting the nbody benchmark test from the 
 Computer Language Shootout to D.

Time ago I have translated to D (D1, mostly) all Shootout benchmarks. Here you see two versions: http://shootout.alioth.debian.org/debian/performance.php?test=nbody
 BTW, in that benchmark D, with my clean implementation, would perform 
 similar to "Clean", about 1.7x slower than the fastest, Fortran. That is 
 with GDC and all optimizations. DMD a bit behind with a 2.1x elapsed 
 time. Both are behind Java, C and C++.

Fortran was designed to run as fast as possible right this kind of programs. D1 code compiled with LDC is about as fast as naive C n-body code (I have said naive version because in D you can't use intrinsics as __builtin_ia32_sqrtpd() as in one more advanced C++ version). Bye, bearophile
Mar 26 2011
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
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.

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.


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(); ?
Mar 24 2011
prev sibling next sibling parent piotrek <starpit tlen.pl> writes:
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.

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.


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
Mar 24 2011
prev sibling next sibling parent piotrek <starpit tlen.pl> writes:
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.

body is also a html tag Cheers Piotrek

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.


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
Mar 24 2011
prev sibling next sibling parent piotrek <starpit tlen.pl> writes:
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.

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.


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
Mar 24 2011
prev sibling parent piotrek <starpit tlen.pl> writes:
On Fri, 25 Mar 2011 10:09:25 +0100, Don wrote:

 piotrek wrote:
 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.

body is also a html tag Cheers Piotrek

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.


situation at all . body (if possible) shouldn't be a keyword. Can anyone from the steering group state his opinion? :)


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. :)

Walter makes all the language decisions. The rest of us have just been able to convince him on multiple occasions (but I think that even Andrei has not achieved 50% convince rate). Hint #1: if you want to convince Walter, produce some real world use cases. Hint #2: you've got more chance if you make a patch, but ONLY if you've satisfied hint 1.

The way the D is managed (in term of language specification) is the key to its success. Walter is like a solid rock. e.g. If he did what bearophile suggests (respect for his work for polishing D) it would be a disaster ;) BTW. I think it would be great if I fall into compiler mechanics, but don't see any chances in the nearest future.
 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)

Priorities. If you spend any time on 'body', that's time taken away from fixing important bugs. The potential benefit is *tiny*. There are 1000 bugs that are more important.

So true. You know, after writing my posts I felt guilty because it could be rated as arrogant. I really appreciate Walter's work and didn't want to make any pressure on him (like I could ;). I'm grateful for him for all amazing staff he did. D is the most beautiful language I have seen. It has its pitfalls, but we know there can't be any perfect one. For now we can live with our "body" :) Speaking of real world examples(is my world really real? :D) I hit "body" when I was doing an html generator. Long before that when I was reading language specification I looked with distaste at the "body" keyword in the contract programming section. Still no big deal. Cheers, Piotrek
Mar 25 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Mar 24 2011
parent Bekenn <leaveme alone.com> writes:
On 3/24/2011 12:55 PM, Steven Schveighoffer wrote:
 I wouldn't mind it becoming a contextual keyword (like C#'s get and set
 inside properties).

This is exactly what it should be.
Mar 24 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 24 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 24 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/25/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 snip

Well, I was really referring to C client-code, not templated D library code, maybe I should have made myself more clear on that :) Generic code uses generic names, it makes the most sense there. So I agree with everything you've said.
Mar 25 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/23/2011 3:17 PM, 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.

Body is not strictly necessary to parse it. But it makes for a nice "anchor" when the in and out clauses get long. In any case, we are currently working on getting temp destruction to work correctly, and after that we'll work on fixing issues with const. I think these are the most important things we should be working on at the moment.
Mar 27 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-27 22:23, Walter Bright wrote:
 On 3/23/2011 3:17 PM, 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.

Body is not strictly necessary to parse it. But it makes for a nice "anchor" when the in and out clauses get long. In any case, we are currently working on getting temp destruction to work correctly, and after that we'll work on fixing issues with const. I think these are the most important things we should be working on at the moment.

I'll be _very_ excited to have both the destructor issues and the const issues sorted out. They are some of the more annoying quality of implementation issues at the moment. I'm not against body no longer being a keyword if it's reasonable to leave the language as-is, as has been suggested here, and not have body be a keyword, but I have to concur that it's not exactly a high priority issue. However, it's much easier to discuss, which is probably part of the reason that it's being discussed so much. Then again, in many cases at this point, what we need isn't really more suggestions on how to improve the language or libraries but help in implementing improvements. Suggestions are by no means bad, but given everything else that needs doing and how few people there are to do it, suggestions are not likely to be implemented soon, even if they're good. If no one has done so already, this suggestion would be worth creating an enhancement request in bugzilla for, but I'd much rather see other quality of implementation issues fixed rather than have such an enhancement implemented right now. The enhancement is nicely backwards compatible, so it can be done at any point in time later without breaking any code or having to way for a possible D3. - Jonathan M Davis
Mar 27 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2011 10:35 PM, Jonathan M Davis wrote:
 I'll be _very_ excited to have both the destructor issues and the const issues
 sorted out. They are some of the more annoying quality of implementation
 issues at the moment.

Yes, I agree those are the top priority at the moment, now that we have the 64 bit compiler online and the worst of the optlink issues resolved.
Mar 28 2011