DIP 1026---Deprecate Context-Sensitive String Literals---Community Review Round 1

[H. S. Teoh]

On Tue, Dec 03, 2019 at 02:45:31PM +0000, Dennis via Digitalmars-d wrote:
> On Tuesday, 3 December 2019 at 12:38:29 UTC, Andrei Alexandrescu wrote:
> > Waste of labor is sadly a common theme in our community.

That's a bit uncalled for.


> I consider this low-hanging fruit: just deprecating a token takes little
> implementation effort, and reduction in language complexity is (as far as I
> know) always welcome for the usual reasons:
> - less code in dmd
> - less specification text
> - less didactic material / stuff to learn for new D programmers
> - less bug/enhancement reports
> - any tool that re-implements some part of the compiler is easier to make

Agreed, but that can't be the only criterion for removing a feature. By
the same argument, one could make the case for removing templates from
D. Bingo, the language instantly becomes so much easier to parse! And it
greatly simplifies the compiler -- we can delete large sections of it,
in fact! The spec becomes simpler, D newbies don't need to learn this
hard template stuff anymore, and we can close all template-relateed
bugs, and tools become greatly simplified.


> In this case, such tools would be syntax highlighters. There are lots
> of syntax highlighting implementations for D, just a few off the top
> off my head:
> - GitHub
> - Code-d
> - Kate
> - Atom
> - Sublime
> - Chroma
> - Vim
> - Emacs
> - Notepad++
> - ...
> 
> They all tend to use their own domain specific language, and I'm
> pretty sure most of them are not powerful enough to express
> identifier-delimited strings.

Are you sure? Adam just gave an example of correct heredoc highlighting
in vim.  It may not be *trivial*, but it's possible.  And users don't
have to worry about it, somebody writes the snippet once for all, and
everyone else can just reuse it.


[...]
> If we don't want D support in syntax highlighters to be half-baked
> everywhere, keeping the lexical grammar simple is a good cause.

IOW, implementators aren't competent enough to implement something up to
spec, therefore we should dumb down the spec for their sake? Sounds like
a backwards reason for doing something.


> I can improve the rationale for this DIP with examples like in this
> post, though if you're absolutely adamant that this is a waste of
> effort then that won't help obviously.
> 
> Maybe you don't care about syntax highlighting, but please judge this
> DIP by its own merits and not compared to potential other DIPs that
> you care more about.

The problem with this DIP is that it removes a marginal feature for no
good rationale, breaking a pretty long list of existing D code projects
that depend on said feature, while offering very little in return
(nothing that can't be fixed another way, e.g., fix broken syntax
highlighters so that they work properly(!)). And it does so without
considering why this feature might have been added in the first place,
what kind of problems it solves, and how said problems can be mitigated
if the feature was removed.

As I've already said, I work a lot with code generators and other code
that embed long-ish text passages in code.  Heredoc syntax is ideal for
this sort of code, allowing you to temporarily "escape" from D syntax
and write code snippets as-is, rather than require onerous escaping
which makes said text less readable. E.g., if I want to embed a mini
Perl script inside a function, I couldn't write it as a token string
(some Perl tokens are not D tokens), and writing it as a quoted string
induces Leaning Toothpick Syndrome, making it hard to edit the script.
The script itself is short enough it doesn't seem worth creating it as a
separate file (and then needing to fight with paths to find it in the
right place).  Heredoc syntax lets me just write the danged script in
situ and move on already, instead of fighting with Leaning Toothpick
Syndrome or heaping on yet another layer of pathname resolution code
just to find a miserable 5-line script file.

Same goes for embedded long-ish text (don't have to type ""~ all over
the place), etc..

It's marginal, yes, but heredocs are quite useful for the use cases they
were intended to be used, and I really don't see why they should be
singled out among so many other things that D could stand to improve in.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher