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,

special meaning in certain contexts but are otherwise available 

identifiers, but you have use the  for syntax to disambiguate 
(e.g. see http://rextester.com/JBOTC21251). From my experience of 

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,

in

 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

 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.


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