Re: Delimiters for pragmas

> I think we also have to ask (and indeed answer) the question: what would this look like in the vXML version of the grammar?  The information should be preserved.

Does this imply that an ixml grammar parser will/should behave differently from an ixml input parser? Presumably, the recognisers would be doing exactly the same job, but the parsers would need to create different outputs, since we wouldn’t normally want an input parser to include pragmas in the vxml representation. 

Another option, I suppose, is to treat the full XML representation of an ixml grammar as a downstream output, with pragmas added as a post-processing step.

Are there reasonable alternatives to these two options? Or am I wrong in some of my assumptions?


> On 1 Feb 2022, at 21:18, Tom Hillman <tom@expertml.com> wrote:
> 
> 
> As I said in the meeting:
> 
> {[implementation comment]} is not enough for me.  There needs to be a label for the pragma, as there has been in both our proposal and Steven’s straw man.  That is leaving aside for now (with the absolute intention that it must be somehow resolved later) questions about what the form of that label should be, and whether it needs to address name collision.
> 
> I think we also have to ask (and indeed answer) the question: what would this look like in the vXML version of the grammar?  The information should be preserved.
> 
> Thanks,
> Tom
>> On 1 Feb 2022, 5:19 PM +0000, Norm Tovey-Walsh <norm@saxonica.com>, wrote:
>> Steven Pemberton <steven.pemberton@cwi.nl> writes:
>>> One way to combat that is to make it clear that pragmas have no effect
>>> on the language: by making them a subset of comments, it is a clear
>>> message that there can be no substantive effect,
>> 
>> I can see, and I’m sympathetic to, this argument on psychological
>> grounds, but it can’t be made on technical grounds. Let’s take John’s
>> hypothetical example of a “fred” comment to the processor that has the
>> effect of making the grammar insensitive to case within a given rule.
>> 
>> If my processor is willing to implement this behavior then the syntax
>> doesn’t matter. If ixml has a pragma syntax, that’s what I’ll implement:
>> 
>> [fred] rule: productname, value.
>> 
>> if it has a standard mechanism for identifying “implementation
>> comments”, that’s what I’ll implement:
>> 
>> {[fred]} rule: productname, value.
>> 
>> and if it has nothing, I’ll invent my own hack in comments (if I don’t
>> just extend the grammar), and that’s what I’ll implement:
>> 
>> {#fred} rule: productname, value.
>> 
>>> because removing comments can have no effect on the language.
>> 
>> Removing that comment *will* have an effect on the language in my
>> implementation. Saying it’s in a comment will not, can not, and does not
>> change that.
>> 
>> Likewise, saying that my processor is non-conformant in this case, which
>> might very well be true, has no more or less (technical) force than
>> saying a pragma that implements this behavior is requiring the processor
>> to behave in a nonconformant way.
>> 
>>> Making pragmas something different where the only intended audience is
>>> implementations, and each implementation can do its thing runs the
>>> risk of implementations using it as a playground for ixml divergence,
>>> and as a place where implementations can satisfy use cases without
>>> making them a standardised part of the language.
>> 
>> I can see how one form invites play and the other simply cannot forbid
>> it. I’m not entirely persuaded, but I also take your point about
>> committees doing design and how long that takes. If
>> 
>> {[implementation comment]}
>> 
>> Is the best we can do under the current constraints, I think I can live
>> with that.
>> 
>> Be seeing you,
>> norm
>> 
>> --
>> Norm Tovey-Walsh
>> Saxonica

Received on Wednesday, 2 February 2022 00:52:59 UTC