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

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.

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

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.

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.

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

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.

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

:-)

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

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

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