Re: pointers to pragmas proposal and other material

2022-01-26

Response to MSM email, 15:44 26 Jan.

* 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)

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

Nor can I find it in the referred documents, sorry. My hand notes indicate it
follows after 'attribute grammar specification'.


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

MSM: I am not sure what "these rules" are.

A pragma refers to (modifies) a rule / rules. My question was (other
than the pragma location within the ixml input grammar,
e.g. after a nonterminal) how is the rule located? It appears tenuous to me?

Your assumption is correct, though I agree the 'link' could easily be broken!

Re 'group of rules' I note the retraction.


"I don't understand it, ignore it."  Makes sense and aligns with my
understanding.

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

If a processor does not understand a pragma, it should ignore it.

I was being a bit more black hat Michael? A pragma in 'my' namespace,
i.e. I should understand it, but don't? Do I halt? Report an error (in
'my' namespace?) What?

<q>
> 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. </q>
Could we have this as an agenda item (some time in the future) please?

<q src='msm'>The operational semantics of an individual pragma are the
responsibility
of the people who define what those pragmas mean.</q>

I'd like this added to the above agenda item please.

(I'd like to understand your meaning from 'operational semantics' Michael?

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

Perhaps you misundertood me? I was asking if this was an example of
'text injection'?

MSM: 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.

Which leaves me wondering how a syntax tree is modified (without some
programming language code?

regards Dave P


On Wed, 26 Jan 2022 at 15:44, C. M. Sperberg-McQueen
<cmsmcq@blackmesatech.com> wrote:
>
>
> 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



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.

Received on Wednesday, 26 January 2022 16:42:00 UTC