Re: weird \s

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Sat, Apr 04, 2020 at 01:08:12AM +1100:

> I'm sorry to break with the consensus that's building around your
> post, but I don't find it part of it reasonably implementable.

Even though having a few postings expressing agreement certainly
looks like emerging consensus, i'm not convinced there is consensus.
For example, i found that posting you are replying to very hard to
read, in particular due to its poor English grammar.  So the overall
intention remained unclear to me, and not all the details that i
could understand were convincing, so i chose to not respond.

That said, i agree with all you are saying in this posting, Branden.


> However I am reminded of the problem of what to do in the "arbitrary
> delimiter" case.  I directed a question to the list in my exchange with
> Ingo.  I would ask that people read our exchange[1].

Sorry for not responding to everything instantly, i struggly to keep
up with everything that is going on in various projects.

> It's not _Bleak House_.  Not quite.

Actually, i love _Bleak House_, i even re-read it from time to time.
But no, you shouldn't have to wait for a judgement as long as
Mr. Gridley did regarding the house in Shropshire.  :-/


I'll only comment on a few points.

You say that lack of context in an error message is "easily fixable".
But in general, experience teaches that it is *not* an easy task
to nicely describe the context of an error (e.g. which request,
escape, macro etc. it appeared in, and the like) in an error message,
for multiple reasons: in *some* situations, doing this exhaustively
can become wordy; in some situations, constructing a description
of nested or otherwise complex syntax in English words for a message
can be technically difficult; in *some* code called from multiple
places, an issue may have arisen from different contexts, and sorting
out which context actually caused it can be non-trivial; sometimes,
a seemingly obvious description can have downsides that require
consideration (like the \s vs. .ec issue you discussed at length),
and so on.  It is of little use to discuss this in generalities.
It typically requires a tradeoff between conciseness, clarity,
amount of detail, and complexity of the implementation of the error
message for each individual case.

> I'd prefer to refer to the construct by what it _is_ rather than how
> it's rendered.
> Putting "\s" in the diagnostic seems brilliantly clear until someone
> uses the .ec request.

I strongly agree.  One of the aspects to consider in the tradeoff
mentioned above is that using overly specific terms can cause
confusion when a problem can result from different contexts, in
this case \s or .ec+something-s.  The wording "point-size escape"
you propose may be adequate because it is concise, accurate, and
readable, but that is not the full tradeoff until you see the final
message, and also consider how it compores to other existing messages.
Using "\s" might perhaps also be acceptable, for example if messages
otherwise become too wordy, given that .ec might be considered kind
of a fringe topic.

(On a side note, allowing alternative syntax that does the same is
a bad idea when designing a language.  Among many reasons why that
is so, one reason is that it forces error messages to be less
specific and hence harder to understand, and hence the language
become harder to use for no benefit.  In that light, inventing .ec
was a terrible language design mistake that should never have been
permitted.  It was also absolutely useless, which i have proven by
implementing logic in the mandoc pre-parser that eliminates .ec
before even starting the main parse sequence.  So all that can be
done with .ec can trivially be done without it as well.  But that
is tangential to the point being discussed.)

> Also, one of the reasons Ingo disliked my (now reverted) commits is
> that they increased the ratio of diagnostics-per-parse-error above
> one.

Indeed.  Conciseness is of critical importance in error messages.
Emitting two messages for the same problem is usually a bad idea,
and even in the very exceptional case where it is justified, no
information from one should be repeated in the other.

To be constructive, i suggest considering small, focussed patches
that Branden is currently preparing.  That is likely to result in
progress, i think.

Yours,
  Ingo