DIP 1026---Deprecate Context-Sensitive String Literals---Community Review Round 1
dkorpel at gmail.com
Tue Dec 3 20:51:26 UTC 2019
On Tuesday, 3 December 2019 at 19:42:12 UTC, Andrei Alexandrescu
> These can never be the primary reasons for removing a feature.
> One doesn't remove a feature because it's easy to remove. One
> removes a feature because there are good reasons to remove it,
> and as perks we get simplification of the language and maybe
> it's easy to remove.
The DIP mentions:
- D's flagship parser generator Pegged can't express the D
grammar (without user defined parser functions)
- Syntax highlighters such as the one on Rosetta code have
trouble with it
- there is precedent of deprecating hexstring literals
I'll admit that the rationale section is not clear in the
"primary reasons" to remove it, but I considered reducing
language complexity an obvious win.
Every feature is a trade off between what it brings to the table
and what it costs, and when it turns out the benefit of a feature
is low it gets removed, even when it's not inherently
problematic. That's what happened with .sort, .reverse, Floating
point NCEG operators, octal literals, hexstring literals, escape
Please answer this: Do you think there were good reasons to
deprecate hexstring literals, or do you consider that a mistake /
> FIRST paragraph in the rationale: "Regarding language design,
> Walter Bright has stated: [... CFG stuff ...]"
> Even the "Grammar Changes" section should be a give-away: the
> diff proposed is in the LEXICAL definition
> (https://dlang.org/spec/lex.html), not in the GRAMMAR
> definition (https://dlang.org/spec/grammar.html).
And the very first thing on the grammar page is:
> 3.1 Lexical Syntax
With a link to the lexical grammar page. I consider lexical
grammar part of "the grammar of D", even when the lexer and
parser are separate stages in the compiler. You might say Walter
was exclusively talking about parsing grammar and not lexing
grammar, but considering this part of the quote:
> A context free grammar, besides making things a lot simpler,
> means that IDEs can do syntax highlighting without integrating
> in most of a compiler front end
It mentions syntax highlighting which does not require parsing.
> If syntax highlighters are the primary reason for the DIP, it
> should be the primary reason in the DIP.
I don't want to commit to it as 'the primary reason', but I will
put more emphasis on it in the next iteration.
> If the DIP requires a forum post explaining how it needs to be
> judged, that's a problem with the DIP, not the reader.
Your first reply came across as "this is useless, please work on
That felt like a destructive comment. This reply actually has
constructive feedback, which helps. Thanks for that.
I will be more specific when talking about 'the grammar', give
some more focus on syntax highlighters and maybe dive more into
the precedent of reducing language complexity by removing
More information about the Digitalmars-d