www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allows the use of part of the language keywords?

reply Brian <zoujiaqing gmail.com> writes:
Allows the use of part of the language keywords, example:

```D
package application.module.user.model;

class User
{
     // TODO
}
```

[code]
sturct module
{
     // TODO
}
[code]

PS: editor don't support markdown or bbcode?- -
Aug 26 2016
next sibling parent reply Cauterite <cauterite gmail.com> writes:
On Friday, 26 August 2016 at 14:16:27 UTC, Brian wrote:
 package application.module.user.model;
I get "Error: identifier expected following '.' instead of 'module'" So I'm not sure how that compiles for you.
Aug 26 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, August 26, 2016 17:59:39 Cauterite via Digitalmars-d wrote:
 On Friday, 26 August 2016 at 14:16:27 UTC, Brian wrote:
 package application.module.user.model;
I get "Error: identifier expected following '.' instead of 'module'" So I'm not sure how that compiles for you.
I think that he's looking for a language change that would allow you to use keywords in contexts where the keyword would not be valid. It's been suggested before, but it was rejected. If nothing else, it doesn't at all play nicely with how lexers and parsers normally work. It's _far_ cleaner if the compiler can treat a keyword as a keyword in all contexts that it's used. Not doing so makes the grammar context-dependent, whereas Walter has gone to great lengths to make it completely context-free. - Jonathan M Davis
Aug 26 2016
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 08/26/2016 11:58 AM, Jonathan M Davis via Digitalmars-d wrote:
 On Friday, August 26, 2016 17:59:39 Cauterite via Digitalmars-d wrote:
 On Friday, 26 August 2016 at 14:16:27 UTC, Brian wrote:
 package application.module.user.model;
I get "Error: identifier expected following '.' instead of 'module'" So I'm not sure how that compiles for you.
I think that he's looking for a language change that would allow you to use keywords in contexts where the keyword would not be valid. It's been suggested before, but it was rejected. If nothing else, it doesn't at all play nicely with how lexers and parsers normally work. It's _far_ cleaner if the compiler can treat a keyword as a keyword in all contexts that it's used. Not doing so makes the grammar context-dependent, whereas Walter has gone to great lengths to make it completely context-free. - Jonathan M Davis
My understanding is completely different: The OP is looking for code highlight support on the forum. :D (Which actually is a newsgroup but I think the forum does support highlighting.) Ali
Aug 26 2016
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 26.08.2016 20:58, Jonathan M Davis via Digitalmars-d wrote:
 On Friday, August 26, 2016 17:59:39 Cauterite via Digitalmars-d wrote:
 On Friday, 26 August 2016 at 14:16:27 UTC, Brian wrote:
 package application.module.user.model;
I get "Error: identifier expected following '.' instead of 'module'" So I'm not sure how that compiles for you.
I think that he's looking for a language change that would allow you to use keywords in contexts where the keyword would not be valid. It's been suggested before, but it was rejected. If nothing else, it doesn't at all play nicely with how lexers and parsers normally work. It's _far_ cleaner if the compiler can treat a keyword as a keyword in all contexts that it's used. Not doing so makes the grammar context-dependent, whereas Walter has gone to great lengths to make it completely context-free. - Jonathan M Davis
No, this would not introduce any context-dependence. https://en.wikipedia.org/wiki/Context-free_grammar That doesn't mean it is necessarily a great idea though. It increases ambiguity of the grammar, and hence, if you want to be able to parse things like auto enum = 3; enum +=2; then not-entirely-trivial disambiguation has to be added to the parser. There's no ambiguity for the example in the OP though.
Aug 27 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2016 6:01 AM, Timon Gehr wrote:
 then not-entirely-trivial disambiguation has to be added to the parser. There's
 no ambiguity for the example in the OP though.
It also: 1. mucks with the usability of syntax highlighting, which is often based merely on tokens. 2. makes it potentially much more difficult to add features to the language, which is often done by finding new uses for the same keywords 3. is just plain confusing to the person learning the language 4. makes correctly diagnosing syntactic errors harder There are a million words in the english language. Having a handful of reserved words should not be a burden.
Aug 27 2016
parent reply Meta <jared771 gmail.com> writes:
On Saturday, 27 August 2016 at 19:21:52 UTC, Walter Bright wrote:
 It also:

 1. mucks with the usability of syntax highlighting, which is 
 often based merely on tokens.
 2. makes it potentially much more difficult to add features to 
 the language, which is often done by finding new uses for the 
 same keywords
 3. is just plain confusing to the person learning the language
 4. makes correctly diagnosing syntactic errors harder

 There are a million words in the english language. Having a 
 handful of reserved words should not be a burden.
Could we at least make body a contextual keyword? It's a commonly used word in many different areas.
Aug 27 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Saturday, 27 August 2016 at 20:45:56 UTC, Meta wrote:
 On Saturday, 27 August 2016 at 19:21:52 UTC, Walter Bright 
 wrote:
 It also:

 1. mucks with the usability of syntax highlighting, which is 
 often based merely on tokens.
 2. makes it potentially much more difficult to add features to 
 the language, which is often done by finding new uses for the 
 same keywords
 3. is just plain confusing to the person learning the language
 4. makes correctly diagnosing syntactic errors harder

 There are a million words in the english language. Having a 
 handful of reserved words should not be a burden.
Could we at least make body a contextual keyword? It's a commonly used word in many different areas.
YEAH! PLEASE-PLEASE-PLEASE-PLEASE! i did that, and it never broke anything for years. as for syntax highlighters -- it's not too hard to check if `body` is followed by `{`. but getting our precious `body` back will be invaluable!
Aug 27 2016
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 28 August 2016 at 02:35:57 UTC, ketmar wrote:
 On Saturday, 27 August 2016 at 20:45:56 UTC, Meta wrote:
 On Saturday, 27 August 2016 at 19:21:52 UTC, Walter Bright 
 wrote:
 It also:

 1. mucks with the usability of syntax highlighting, which is 
 often based merely on tokens.
 2. makes it potentially much more difficult to add features 
 to the language, which is often done by finding new uses for 
 the same keywords
 3. is just plain confusing to the person learning the language
 4. makes correctly diagnosing syntactic errors harder

 There are a million words in the english language. Having a 
 handful of reserved words should not be a burden.
Could we at least make body a contextual keyword? It's a commonly used word in many different areas.
YEAH! PLEASE-PLEASE-PLEASE-PLEASE! i did that, and it never broke anything for years. as for syntax highlighters -- it's not too hard to check if `body` is followed by `{`.
You must keep track of the previous token, which is not usually done in a scanner. Once again, the D style says to add a "_" after the keyword. If it's a problem with the reflection it's also easy to check if an identifier ends with "_" and then to remove it. The examples of contextual keywords given by W.Bright in a previous message are totally different from the "body" case because in `extern(C)`, "C" is an identifier that becomes a keyword in the context, while what you propose is that a keyword becomes an identifier out of the context.
Aug 27 2016
next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Sun, 28 Aug 2016 04:32:46 +0000, Basile B. wrote:
 Once again, the D style says to add a "_" after the keyword. If it's a
 problem with the reflection it's also easy to check if an identifier
 ends with "_" and then to remove it.
Or use UDAs, which would be more general.
Aug 27 2016
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sunday, 28 August 2016 at 04:32:46 UTC, Basile B. wrote:
sorry, i cannot find where exactly i was asked about workaround 
for "stolen body" case. maybe it's 'cause i DIDN'T ASKED FOR 
WORKAROUND?
Aug 27 2016
prev sibling parent reply Cauterite <cauterite gmail.com> writes:
On Sunday, 28 August 2016 at 04:32:46 UTC, Basile B. wrote:
 You must keep track of the previous token, which is not usually 
 done in a scanner.
That sounds like a pretty trivial feature to me. There's no way that's a legitimate obstacle.
Aug 28 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 28 August 2016 at 08:07:27 UTC, Cauterite wrote:
 On Sunday, 28 August 2016 at 04:32:46 UTC, Basile B. wrote:
 You must keep track of the previous token, which is not 
 usually done in a scanner.
That sounds like a pretty trivial feature to me. There's no way that's a legitimate obstacle.
Look at this, this is perfectly valid D code: void main() in {} body /**/ #line 8 /**/ // /+ /+ +/ +/ {} to think that it can be detected with a simple lookup backward (or forward from the KW) is too simplistic.
Aug 28 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sunday, 28 August 2016 at 08:25:38 UTC, Basile B. wrote:
 On Sunday, 28 August 2016 at 08:07:27 UTC, Cauterite wrote:
 On Sunday, 28 August 2016 at 04:32:46 UTC, Basile B. wrote:
 You must keep track of the previous token, which is not 
 usually done in a scanner.
That sounds like a pretty trivial feature to me. There's no way that's a legitimate obstacle.
Look at this, this is perfectly valid D code: void main() in {} body /**/ #line 8 /**/ // /+ /+ +/ +/ {} to think that it can be detected with a simple lookup backward (or forward from the KW) is too simplistic.
i have a perfect solution to this: don't write such code!
Aug 28 2016
parent reply Chris Wright <dhasenan gmail.com> writes:
On Sun, 28 Aug 2016 08:35:06 +0000, ketmar wrote:
 i have a perfect solution to this: don't write such code!
It would reflect poorly on the compiler if it failed to compile something simply because you added a few comments. Especially since each C-style comment is likely its own token. A not-absurd usecase is a person condensing several functions into one, which might involve separately commenting out several function bodies.
Aug 28 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sunday, 28 August 2016 at 13:26:26 UTC, Chris Wright wrote:
 On Sun, 28 Aug 2016 08:35:06 +0000, ketmar wrote:
 i have a perfect solution to this: don't write such code!
It would reflect poorly on the compiler if it failed to compile something simply because you added a few comments. Especially since each C-style comment is likely its own token. A not-absurd usecase is a person condensing several functions into one, which might involve separately commenting out several function bodies.
it has nothing to do with compiler: parser skips comments when peeking tokens. the only thing affected is simplistic syntax highlighter that can't do proper lookup.
Aug 28 2016
parent Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
On Sunday, 28 August 2016 at 13:35:59 UTC, ketmar wrote:
 it has nothing to do with compiler: parser skips comments when 
 peeking tokens. the only thing affected is simplistic syntax 
 highlighter that can't do proper lookup.
I have anyway never seen the necessity of the keyword "body" anyway. I fact, I very much dislike it. You could write a function Fn() in {} out() {} {} or even better (or at least what I would prefer): Fn() {} in {} out() {} The parser will always take the block without preceeding keyword as the body. If you leave out "in" and "out", you also don't need the keyword body. As soon as you add a contract, suddenly you have to add that nasty "body". As I learned D this was confusing and I still fail to see the benefit. If you really feel the need to make explicit where the body starts, you can add a comment: Fn() in { } // body: { } out() { }
Aug 29 2016
prev sibling parent Cauterite <cauterite gmail.com> writes:
On Sunday, 28 August 2016 at 08:25:38 UTC, Basile B. wrote:
 to think that it can be detected with a simple lookup backward 
 (or forward from the KW) is too simplistic.
I'm not saying it'd necessarily be easy to distinguish keyword 'body' from identifier 'body' in the lexer, I'm just saying a 'look-behind' feature in a lexer would be trivial to implement.
Aug 28 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2016 7:35 PM, ketmar wrote:
 getting our precious `body` back will be invaluable!
You are not of the body! https://www.youtube.com/watch?v=m48xii7ndcg
Aug 27 2016
prev sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Friday, 26 August 2016 at 18:58:25 UTC, Jonathan M Davis wrote:
 On Friday, August 26, 2016 17:59:39 Cauterite via Digitalmars-d 
 wrote:
 On Friday, 26 August 2016 at 14:16:27 UTC, Brian wrote:
 package application.module.user.model;
I get "Error: identifier expected following '.' instead of 'module'" So I'm not sure how that compiles for you.
I think that he's looking for a language change that would allow you to use keywords in contexts where the keyword would not be valid. It's been suggested before, but it was rejected. If nothing else, it doesn't at all play nicely with how lexers and parsers normally work. It's _far_ cleaner if the compiler can treat a keyword as a keyword in all contexts that it's used. Not doing so makes the grammar context-dependent, whereas Walter has gone to great lengths to make it completely context-free. - Jonathan M Davis
As Timon said, this won't make the grammar context dependent. Also, C# has the concept of contextual keywords. Such keywords have special meaning in certain contexts but are otherwise available for use as identifiers. C# also allows to use normal keywords as identifiers, but you have use the for syntax to disambiguate (e.g. see http://rextester.com/JBOTC21251). From my experience of using C# the system is well designed and I have never seen problems in practice. I'm sure something similar can successfully be implemented for D. Though I would consider such enhancement with low priority. See https://msdn.microsoft.com/en-us/library/x53a06bb.aspx for more info.
Aug 27 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2016 6:36 AM, ZombineDev wrote:
 As Timon said, this won't make the grammar context dependent. Also,
 C# has the concept of contextual keywords. Such keywords have special meaning
in
 certain contexts but are otherwise available for use as identifiers. C# also
 allows to use normal keywords as identifiers, but you have use the  for syntax
 to disambiguate (e.g. see http://rextester.com/JBOTC21251). From my experience
 of using C# the system is well designed and I have never seen problems in
 practice. I'm sure something similar can successfully be implemented for D.
 Though I would consider such enhancement with low priority.

 See https://msdn.microsoft.com/en-us/library/x53a06bb.aspx for more info.
D has contextual keywords, too, and has had them since the beginning: extern (C) pragma (msg, ...) scope (exit) etc. Microsoft has tried to patent contextual keywords in C#, but I don't think they have a case.
Aug 27 2016
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 26 August 2016 at 14:16:27 UTC, Brian wrote:
 Allows the use of part of the language keywords, example:
 [code]
 sturct module
 {
     // TODO
 }
 [code]
The D style as used in phobos says that you must add a "_" at the end of the keyword that you wish to use as identifier. When the problem happens because of linkage to an object or to a static library there's the pragma(mangle): https://dlang.org/spec/pragma.html#mangle
 PS: editor don't support markdown or bbcode?- -
No, but people use several tricks to denote a code block: github style block code, html tags etc. This times I use °°°°°°°°°°°°°°°°°°
Aug 27 2016
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 26 August 2016 at 14:16:27 UTC, Brian wrote:

 PS: editor don't support markdown or bbcode?- -
See this: http://dlang.org/blog/2016/06/10/core-team-update-vladimir-panteleev/
Aug 27 2016