Re: On pragmas…

Steven Pemberton writes:

> Sorry, coming to this late. Busy week.
>
>> 1. What are pragmas?

>> They’re mechanism for a grammar author to signal that something is
>> special about some part of the grammar.

> Which I disagree with. At least what I thought we'd agreed on at the
> beginning when Michael and Tom went off to design a notation.

Excuse me, but I don't understand.

You don't agree that pragmas are a mechanism for signaling something
special about the input?

In the past you have described pragmas as a mechanism for communicating
with the processor.  Does "signal[ing] that something is special about
some part of the grammar" not fall into that category?

I think Norm's wording covers a common, perhaps the most common, maybe
even the almost exclusive use case.  But as a matter of definition, I
think pragmas, like processing instructions or extension elements in XML
vocabularies, are more broadly mechanisms for communicating in ways not
standardized by the host spec (here: ixml; in the case of processing
instructions and extension elements: XML and whatever spec defines the
host vocabulary).

If we are communicating with an ixml processor, it is not necessary to
use a pragma to communicate information already communicated by the
grammar, so I think the only plausible use cases for pragmas are for
communicating information that is not expressible using ixml as
specified.  

> I was anticipating a mechanism to signal to the processor "Use a
> different input encoding" "Use a different parser" "Output all parses"
> "Don't mark serializations as ambiguous", etc.

These all involve information not expressible using ixml.

They also all involve information that, from a modeling viewpoint,
applies more to a particular invocation of a processor than to the
grammar.  They could all equally well be handled by run-time options or
user-level default configuration of the processor.  (There is a sort of
gray area, to be sure: If a particular grammar is known to be harmlessly
ambiguous, or to be deterministic, then I might want to specify 'do not
mark ambiguity' or 'use an LL(1) parsing algorithm' every time I use
that grammar, so putting that information in the grammr would make
sense.  A bit like "this module is a hotspot of the application, so
always compile it with the highest optimization level" or "this module
defeats the level-4 optimizer, so just use level 3".)

> I was absolutely not expecting a mechanism to change the
> interpretation of ixml, in any way at all.

What did you think a pragmas proposal would be good for, if not as a way
of requiring that any changes to the standard interpretation of ixml
should be marked as such, so that users who wish to rely on
interoperability can know when they may be relying on non-standard
behavior?

During the years I have used computers, I have observed that "I would
like you to handle this input specially" is one of the most common cases
of a need for a non-standard communication path to an application, and
that in many common cases the special handling involves an extension to
the standard defined by the relevant spec.

In some specs, mechanisms for specifying special handling, including
extensions to the standard language, are called pragmas.  I am not aware
of any specs that define things they call "pragmas" that are restricted
to meanings approved by the writers of the spec.

So when I suggested that ixml should have a pragmas mechanism, and the
CG asked Tom and me to prepare a proposal, I would have been surprised
to learn that some members of the CG apparently speak a variant of
English in which "pragma" means something different from what it means
in C++, or C, or Algol 68 (where it is spelled 'pragmat'), or Ada, or
what I perceive to be common usage.  In those discussions I explicitly
mentioned the use case of adding support for attribute grammar
specifications to ixml, which quite definitely goes beyond what one
could plausibly specify as a run-time option to the processor.

You may say, if you wish, that you were surprised by the content of the
proposal Tom and I produced, or shocked by the discovery that the group
has misunderstood each other when discussing the idea of pragmas.  But I
wish you would make an effort to stop suggesting that the proposal is a
product of bad faith or that it in any way goes beyond what was actually
agreed.  I was willing to overlook it the first four or five times you
implied that Tom and I had gone off the rails, but over time it has
gotten a bit old.


Michael



-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Tuesday, 29 March 2022 17:34:54 UTC