Compile time and runtime grammars

DLangLearner via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat Oct 10 11:52:29 PDT 2015


Only now I found that most of my confusions are with D's compile 
time grammar or features. As an excuse, my confusions can be 
partially attributed to the way D is presented:

1. There are confusing keywords:
For example, there is a "if", there is also a "static if", there 
is a "if", and there is an "is()". For new learners like me, they 
cause confusion at least uneasiness.

2. Compile time grammar spreads among runtime grammar
Most documents present D's compile time grammar and runtime 
grammar in the same time. It made me feel that D's grammar is not 
consistent because compile time grammar seem to be exceptions 
from runtime grammar. If a document talks exclusively about 
runtime grammar first, and
introduces compile time grammar late, I think this will make 
readers accept those seemingly conflicting grammar. In fact 
without introducing compile time grammar, D is much similar to 
other languages, in this way the readers from other languages can 
find D more friendly.

With the understanding of D's compile time grammar, I can read D 
codes from other projects such as std packages, but I am still 
not easy about the way that D's compile time codes are not 
clearly distinguished from runtime codes. I am wondering if it is 
a good idea to clearly indicate those compile time codes with a 
special identifier say "@ct", or prefix "__" as in __traints, if 
so then those "inconsistencies" can be resolved as follows:

static if -> @ct if
static assert" -> @ct assert
enum fileName = "list.txt" -> @ct  fileName = "list.txt"
is (string[void]) -> @ct is (string[void])
mixin(`writeln("Hello World!");`) -> @ct `writeln("Hello 
World!");`

So this post is not quite a question, just a thought in my mind 
after I am able to differentiate compile time codes from runtime 
codes.


More information about the Digitalmars-d-learn mailing list