Re: Delimiters for pragmas

> - Michael/Tom, what else would you need to see added to this proposal as an absolute bare minimum before you could support it?

I think I can only make a statement about support when we have a complete proposal: what you have suggested seems fine, so far, to me, but there is still much that we addressed in our proposal which is left undefined here, even aside from the fairly major issues about what label and pragma-data are.

For instance, where can we put pragma?

Thanks,
Tom
On 2 Feb 2022, 01:05 +0000, Bethan Tovey-Walsh <accounts@bethan.wales>, wrote:
> Would it be at all fruitful to talk about what we would need to add to the {[ ]} syntax to satisfy those who are not currently satisfied? And whether those things can be added without tipping the balance back in the other direction as far as Steven’s concerned?
>
> As a start:
>
> - Steven, would you object in principle to adding a label to the definition of a pragma, so that
>
> pragma : “{[“, label, pragma-data?, “]}”.
>
> with the form of the label and pragma data to be negotiated?
>
> - Michael/Tom, what else would you need to see added to this proposal as an absolute bare minimum before you could support it?
>
>
> > 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
>