Re: pointers to pragmas proposal and other material

Dave Pawson writes:

> My view / comments / issues with pragmas.
>
> Attached, md format.

Thank you.  Some responses to individual points follow.

> ## Applicability

> ...
> * Attribute grammar specification (I don't understand this - would
>   someone explain pse)

Attribute grammars are a formalism that extends a base context-free
grammar by specifying sets of 'attributes' (or 'properties') for each
nonterminal in the grammar, together with rules about how to calculate
the values of attributes from the data in the input or from the values
of other attributes.  They were first formalized, if I recall correctly,
by Donald Knuth in 1968, and Knuth gives credit to various other people
for their work anticipating the idea.

Many people find attribute grammars useful as a way of describing in a
formal and declarative way rules that would otherwise have to be
expressed in natural-language prose.

Their relevance to a discussion of pragmas is simple: writing an
attribute grammar requires writing both a base context free grammar and
annotating it with additional information.

> * Recording the action of applying the ixml input grammar to the ixml
>   input string. (I don't see why this might be a use case)

I do not know what part of what document you're referring to here.

> Question: How are these rules found? By the location within the ixml
> input grammar of the pragma?

I am not sure what "these rules" are.

But assuming that they are rules to which pragmas apply, the question
you ask seems to me to be one which has to be answered for any
annotation mechanism:  given an annotation, how is someone to know what
it applies to?

In the TM pragmas proposal, the grammar rules are constructed so that
any pragma applying to the grammar as a whole is, in the XML version of
the grammar, a child of the 'ixml' element, any pragma applying to a
rule is a child of the 'rule' element, and any pragma applying to a
symbol on the right-hand side of a rule is a child of the XML element
for that symbol.

Of course, since the semantics of pragmas cannot reliably be
constrained, there is no way to prevent the definer of a pragma from
saying "this should be placed before the third rule of the grammar, but
in reality it applies to the fifth and seventhh symbols on the right
hand side of the tenth rule, if the current day is Thursday, and
otherwise to the last symbol of the last rule."  The TM proposal
attempts to make it easier to do rational things, not to make it
impossible to do things that look irrational.

> What of a group? Next n rules?

The pragmas proposal in pragmas-proposal.md provides no mechanism for
applying a pragma to a group of rules.  We entertained that possibility
for a while but found that it complicated the grammar somewhat and its
use cases are rather weak.

> Question: if the pragma is 'not understood' (how defined?), what then?

Under the TM proposal, each behavior or functionality to be specified by
pragmas in an ixml grammar is associated with a QName; groups of related
behaviors can be grouped together in a namespace.  The occurrence of a
given QName in a pragma identifies the behavior in question.

Each ixml processor "understands" (i.e. implements) some
implementation-defined set of QNames used for pragmas, possibly the
empty set.  If the QName of a pragma is not on a processor's list of
implemented pragmas, the processor "does not understand" the pragma and
ignores it.  


> ... If not understood, then what? Halt processing the ixml input
> grammar?

If a processor does not understand a pragma, it should ignore it.  The
standard interpretation of the grammar is unaffected by the presence of
any pragma, so ignoring a pragma will normally be safe.

> If a pragma is being applied to a parse tree, to which tree (at what
> time) is it applied?

> 1. The (pre-pragma) tree?
> 2. The 'modified so far' tree?
> 3. Other?

I do not understand the question, and doubt that there will be a
universal answer.  The operational semantics of pragmas, including the
identity of trees involved in any tree transformations specified by the
pragma, is a matter for the definers of the behaviors in question, not
for the ixml spec.

> ## Authoring pragmas.

> Pragmas can contain XML fragments. Is this the 'text injection' idea?
> or does this happen when the updated ixml input grammar (*pragma
> amended ixml grammar*???) is applied to the ixml input string?

The operational semantics of an individual pragma are the responsibility
of the people who define what those pragmas mean.

A pragmas proposal should ideally make it possible for those who specify
particular behaviors to specify the operational semantics of pragmas,
but it will not (or perhaps I mean should not) itself specify the
operational semantics of pragmas.

To learn what an XML fragment inside a pragma means, consult the person
who specied the pragma.

As the person who worked out many of the worked examples in the document
pragmas.md, I am happy to discuss how those pragmas would work.  But
those pragmas are not part of the TM proposal; they are only
illustrations of how the TM proposal could be applied in practice, just
as the fragments of grammars for CSS in the ixml spec are only
illustrations of how a gramar writer might use ixml to parse CSS. 

> If a pragma 'operates' on / modifies an ixml input grammar, should I
> assume a programming language? Must it be the same as that in which
> the ixml processor was written? How might this code be added to /
> referenced from the ixml input grammar?

The operational semantics of a pragma are the responsibility of those
who define a behavior and assign a QName to it so that the QName can be
used in pragmas in ixml grammars.

I can imagine pragmas that specify that the pragma body contains bits of
executable code, just as I can imagine SGML processing instructions that
contain bits of Spitbol.  I don't necessarily think that either is a
good idea (although I did initially like the Spitbol idea enough to
implement it).

None of the worked examples in pragmas.md assume a full programming
language in pragma data, though there may be one or two that expect a
simple expression language.

> MSM said 'pragma could add functionality not present in the
> specification'? Do we have such a list of missing functionality or is
> it tba?

The set of functionality not present in any spec is presumably infinite;
how would you generate a list that named it all?  

I hope this helps.

Michael

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

Received on Wednesday, 26 January 2022 15:44:59 UTC