On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
> I'm currently writing up a DIP to propose removing `body` as a keyword to allow it to be used for variable names, functions, etc. I'm looking for examples and contexts where `body` would normally be used as a variable, function name, alias, etc. This is what I have come up with off the top of my head:
>
> - In web programming where "body" is a required tag in any valid HTML document. Ex:
> - It is a name commonly used for XML tags and/or attributes
> - Physics simulations as well in astronomical contexts ("planetary bodyies", etc.)
> - Video games, such as referring to the player character's body

I'll be against this. Seriously is it the biggest problem you have with D ?

Also, what I guess is that your DIP will not propose "body" to be removed from the keyword list. You'll propose that "body" will be a keyword only in certain contexts...
and we have already talked about that. You will say that for example "win32" is already used as a special keyword in a versionExpression. And I'll tell you that "win32" is an identifier used as keyword, contextually, while for "body" it's the opposite: It's a keyword that you propose to use as identifier.

On Wednesday, 5 October 2016 at 17:17:32 UTC, default0 wrote:
> On Wednesday, 5 October 2016 at 17:14:04 UTC, Matthias Klumpp wrote:
>> On Wednesday, 5 October 2016 at 16:57:42 UTC, Rory McGuire wrote:
>>> On Wed, Oct 5, 2016 at 5:32 PM, angel via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>>
>>>> On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
>>>> [...]
>>>> Really, why do we need a _body_ ?
>>>> We have pre-condition and post-condition (in and out), everything else is
>>>> a body.
>>>> It is simply inconsistent - a regular function with no in and out blocks
>>>> has no body block. Now one adds a pre-condition (and / or post-condition) -
>>>> whoop - one needs to wrap the whole function body ... well in a body
>>>> expression.
>>>>
>>>
>>> Recently I've had to use scope_ a lot more often than body_ but reserved keywords are really annoying, so the less we have the better :D
>>
>> Agreed - I have exactly the same problem with "version", which is also really common for, well, to hold a version number of a component. Body is annoying too.
>>
>> But, can keywords actually sanely be removed from the language without breaking the world?
>
> To answer the question: if you can make them contextual keywords instead of keywords, then yes. Naturally that will increase complexity for correct syntax highlighting and similar things one may want to do to D code.

I know that Walter is against contextual keywords.  We had a long discussion on this about attributes like nogc.  I made a wiki trying to explain the reasoning behind it:

http://wiki.dlang.org/Language_Designs_Explained#Why_don.27t_we_create_a_special_rule_in_the_syntax_to_handle_non-keyword_function_attributes_without_an_.27.40.27_character.3F

In my opinion, having to write "body_" instead of "body" is a minor annoyance, but just minor.  I'm not sold that contextual keywords are bad, but if they are, then this "keyword" problem is hard to solve, and the current solution isn't so bad. Also, there's alot of other important things to be done with D, I don't think this one is very high on the list.

On Wednesday, 5 October 2016 at 17:51:07 UTC, Basile B. wrote:
> I'll be against this. Seriously is it the biggest problem you have with D ?

Not by a longshot


> Also, what I guess is that your DIP will not propose "body" to be removed from the keyword list. You'll propose that "body" will be a keyword only in certain contexts...
> and we have already talked about that. You will say that for example "win32" is already used as a special keyword in a versionExpression. And I'll tell you that "win32" is an identifier used as keyword, contextually, while for "body" it's the opposite: It's a keyword that you propose to use as identifier.

Please hold the strawmen until the DIP is ready for public viewing.

On 2016-10-05 19:14, Matthias Klumpp wrote:

> Agreed - I have exactly the same problem with "version", which is also
> really common for, well, to hold a version number of a component. Body
> is annoying too.
>
> But, can keywords actually sanely be removed from the language without
> breaking the world?

In Ruby most keywords are not reserved words. Example:

class Foo
  def class
  end
end

When the compiler sees the second "class" it already knows that this is a method declaration because of the "def" keyword. Actually calling this method requires a receiver:

class Foo
  def class
  end

  def bar
    class # this won't compile
    self.class # this will work since the compiler knows that is has to be a method call because of the dot
  end
end

In Scala it's possible to wrap a keyword in backticks, this is necessary to be able to call a Java method that uses a name that is a keyword in Scala but not in Java:

// Java
class Foo
{
    void def () {}
}

// Scala
val a = new Foo()
a.`def`()

-- 
/Jacob Carlborg

On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg wrote:
> On 2016-10-05 19:14, Matthias Klumpp wrote:
>
>> Agreed - I have exactly the same problem with "version", which is also
>> really common for, well, to hold a version number of a component. Body
>> is annoying too.
>>
>> But, can keywords actually sanely be removed from the language without
>> breaking the world?
>
> In Ruby most keywords are not reserved words. Example:
>
> class Foo
>   def class
>   end
> end
>
> When the compiler sees the second "class" it already knows that this is a method declaration because of the "def" keyword. Actually calling this method requires a receiver:
>
> class Foo
>   def class
>   end
>
>   def bar
>     class # this won't compile
>     self.class # this will work since the compiler knows that is has to be a method call because of the dot
>   end
> end
>
> In Scala it's possible to wrap a keyword in backticks, this is necessary to be able to call a Java method that uses a name that is a keyword in Scala but not in Java:
>
> // Java
> class Foo
> {
>     void def () {}
> }
>
> // Scala
> val a = new Foo()
> a.`def`()

To remove D's current keywords and add them to the syntax would be quite an undertaking I think.  If someone was so inclined, they could take the full syntax as it exists today, and try to modify it so that the keywords would be removed and added to the applicable grammar rules.  I'd be curious to see how this would change the syntax rules, if it would be ALOT more complicated or if it only added some minor complication.  My gut says that this would explode in complexity, but maybe not?  You'd also have to make sure that the new syntax is still unambiguous, there's probably tools that can verify this.

On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg wrote:
> On 2016-10-05 19:14, Matthias Klumpp wrote:
>
>> Agreed - I have exactly the same problem with "version", which is also
>> really common for, well, to hold a version number of a component. Body
>> is annoying too.
>>
>> But, can keywords actually sanely be removed from the language without
>> breaking the world?
>
> In Ruby most keywords are not reserved words. a.`def`()

D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.

On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
> On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg wrote:
>> On 2016-10-05 19:14, Matthias Klumpp wrote:
>>
>>> Agreed - I have exactly the same problem with "version", which is also
>>> really common for, well, to hold a version number of a component. Body
>>> is annoying too.
>>>
>>> But, can keywords actually sanely be removed from the language without
>>> breaking the world?
>>
>> In Ruby most keywords are not reserved words. a.`def`()
>
> D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.

Yes the fact that D is context free is a very nice benefit and I can pretty much guarantee that D maintainers will never allow changing the syntax to break this.

However, I believe a context-free grammar could support "contextual keywords".  Note that the word "contextual" here is a bit misleading.  For someone who really wanted to remove body as a keyword, I encourage them to try to modify the syntax and see if they can maintain the "context-free" grammar and without over complicating the syntax.  I'm not sure if it's possible, but it might be.  Anyone up for the challenge?

On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
> On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg wrote:
>> On 2016-10-05 19:14, Matthias Klumpp wrote:
>>
>>> Agreed - I have exactly the same problem with "version", which is also
>>> really common for, well, to hold a version number of a component. Body
>>> is annoying too.
>>>
>>> But, can keywords actually sanely be removed from the language without
>>> breaking the world?
>>
>> In Ruby most keywords are not reserved words. a.`def`()
>
> D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.

In general I don't think this is a problem, but `body` is an unconventional term to have as a keyword. The other keywords that are used for function contracts (`in` and `out`) are also used in other places - perhaps `body` could be deprecated and eventually removed in favor of using another keyword instead? Either another, different keyword that is less likely to collide with common attributes of user types, or an existing keyword not meaningful in the same context.

There may also be a case for making `body` implicit - e.g.

    void func() in{
        //
    }out{
        //
    }body{
        //
    }

Would become

    void func() in{
        //
    }out{
        //
    }{
        //
    }

I don't think this is of critical importance, but dealing with this somehow would definitely be a step in the right direction.

On Wednesday, 5 October 2016 at 19:30:27 UTC, pineapple wrote:
> On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
>> On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg wrote:
>>> On 2016-10-05 19:14, Matthias Klumpp wrote:
>>>
>>>> Agreed - I have exactly the same problem with "version", which is also
>>>> really common for, well, to hold a version number of a component. Body
>>>> is annoying too.
>>>>
>>>> But, can keywords actually sanely be removed from the language without
>>>> breaking the world?
>>>
>>> In Ruby most keywords are not reserved words. a.`def`()
>>
>> D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.
>
> In general I don't think this is a problem, but `body` is an unconventional term to have as a keyword. The other keywords that are used for function contracts (`in` and `out`) are also used in other places - perhaps `body` could be deprecated and eventually removed in favor of using another keyword instead? Either another, different keyword that is less likely to collide with common attributes of user types, or an existing keyword not meaningful in the same context.
>
> There may also be a case for making `body` implicit - e.g.
>
>     void func() in{
>         //
>     }out{
>         //
>     }body{
>         //
>     }
>
> Would become
>
>     void func() in{
>         //
>     }out{
>         //
>     }{
>         //
>     }
>
> I don't think this is of critical importance, but dealing with this somehow would definitely be a step in the right direction.

Sorry Sophie, but do you really think that's consistent to have

in{}
out{}
{}

so the actual body without keyword ?
In this case let's drop completely the contracts...you can put them in the body, at the beg or at the end...The syntax will be less sane but the 4 guys who need "body" as identifier will be happy...

On Wednesday, 5 October 2016 at 19:45:20 UTC, Basile B. wrote:
> On Wednesday, 5 October 2016 at 19:30:27 UTC, pineapple wrote:
>> On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
>>> On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg wrote:
>>>> On 2016-10-05 19:14, Matthias Klumpp wrote:
>>>>
>>>>> Agreed - I have exactly the same problem with "version", which is also
>>>>> really common for, well, to hold a version number of a component. Body
>>>>> is annoying too.
>>>>>
>>>>> But, can keywords actually sanely be removed from the language without
>>>>> breaking the world?
>>>>
>>>> In Ruby most keywords are not reserved words. a.`def`()
>>>
>>> D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.
>>
>> In general I don't think this is a problem, but `body` is an unconventional term to have as a keyword. The other keywords that are used for function contracts (`in` and `out`) are also used in other places - perhaps `body` could be deprecated and eventually removed in favor of using another keyword instead? Either another, different keyword that is less likely to collide with common attributes of user types, or an existing keyword not meaningful in the same context.
>>
>> There may also be a case for making `body` implicit - e.g.
>>
>>     void func() in{
>>         //
>>     }out{
>>         //
>>     }body{
>>         //
>>     }
>>
>> Would become
>>
>>     void func() in{
>>         //
>>     }out{
>>         //
>>     }{
>>         //
>>     }
>>
>> I don't think this is of critical importance, but dealing with this somehow would definitely be a step in the right direction.
>
> Sorry Sophie, but do you really think that's consistent to have
>
> in{}
> out{}
> {}
>
> so the actual body without keyword ?
> In this case let's drop completely the contracts...you can put them in the body, at the beg or at the end...The syntax will be less sane but the 4 guys who need "body" as identifier will be happy...

Sorry, I find the actual body without body keyword much more natural (i.e. intuitive) than having the body requiring it only when there are contracts. It would be even consistent with the template syntax where 1 parenthesis pair is runtime parameter and when there are 2 pairs template+runtime. The genious idea of D was to find that template parameter didn't require the abomination of alternate parenthesis < >. In the same vein, I'm sure that the body keyword is superfluous as the contract statements are unambiguously marked. That body keyword is so "un-D-ic" as it gets.