Re: pointers to pragmas proposal and other material

Dave Pawson writes:

> 2022-01-26
>
> Response to MSM email, 15:44 26 Jan.

>> 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?

Well, a processor reading an ixml grammar has the information in the
ixml grammar, and for pragmas it understands it has whatever information
about the target the definition of that pragma's behavior might provide,
and it has whatever information was provided by the user at invocation
time.

When you specify a behavior to be invoked with pragmas, I guess you have
the ability to choose, and I don't see how any spec could prevent your
choosing.  I also don't see how other people can reliably predict your
choice.

For rational specification of rational pragmas (as far as it is given to
us to understand what counts as rational), the TM proposal provides a
simple way to associate pragmas with individual rules, with individual
symbols in the RHS of a rule, and with the grammar as a whole.  That way
uses the structure of the input grammar as specified by the ixml
specification grammar, so the association of a pragma with a rule is
just as tenuous, but not more tenuous, than the association of a
right-hand side with a left-hand side.

>> ... 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?

Not specified.

The operational semantics of a pragma are the responsibility of those
who define the behavior in question.  Whether, operationally, it is
better to recover from an error encountered while reading the pragma or
performing the behavior, or to halt and catch fire, is a question for
them, not for the ixml spec.  Or for the implementor.

As for me, I expect that if I write a parser that understands some
pragmas, and I detect a syntax error in the pragma-data, I will issue a
warning and carry on, unless the user has specified and invocation
option requesting that I fail in that case.

> <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 don't see an agenda item above or below; I think you must mean the
agenda item calling for further discussion of the pragmas proposal.

What is the 'this' that should be added to it?  A pointer to your mail?
Your question about tree processing and when it happens?  My statement
that the semantics of a pragma is up to the people who specify it?  

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

By 'operational semantics' I mean any explanation of what something
means be describing what it does, or what a program implementing it
does.

If we are talking about a pragma which involves applying some operation
to some tree, and we have questions about when the operation happens and
what tree it happens to, our questions are about the operational
semantics of the pragma (or possibly about the specific behavior of a
processor that implements the pragma).

> 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'?

Possibly I did misunderstand.  But I think I understood that you were
asking if XML fragments occurring inside a pragma would be an example of
text injection.

And my answer is: it depends on the pragma and its meaning.  I don't
know for sure that pragma you are talking about here, and I don't see
any examples in any of the documents in which XML fragments occur within
the ixml form of a pragma.

By "text injection" I understand a mechanism whose effect is that the
XML produced by an ixml processor contains character data or attribute
values which do not occur in the input string.  Since pragmas as I
understand the term appear in ixml input grammars, neither character
data nor XML appearing in them would constitute text injection as I
understand that term.  I can imagine someone specifying "inject the
specified bit of text into the output at this point" as the behavior to
be signaled or requested (or whatever the verb should be) by a pragma,
just as I can imagine the ixml spec being modified to provide a standard
way of specifying that behavior.  But I can't imagine that this
constitutes a satisfactory answer to your question.

> 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?

Pragmas don't implement themselves; programmers implement them.

How is the syntax tree produced by an ixml processor constructed, given
that there is no code in either the ixml input grammar or the input
string?

I hope this helps.

Michael


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

Received on Wednesday, 26 January 2022 17:48:10 UTC