Re: Thoughts on pragmas and iXML

On Mon, Feb 17, 2025 at 09:00:38PM +0000, Bethan Tovey-Walsh scripsit:
> Just because there are no overriding syntactic rules, that doesn't
> mean you cannot know what the semantic rules are, and how they
> interact. You will need to know how the pragma functions, and part of
> that will involve knowing how pragmas interact. If you have a "replace
> this element with a giraffe" pragma and a "avoid replacing this
> element with a giraffe at all costs" pragma, you can't use them
> together. That isn't a syntactic constraint; it's a semantic one. 

I'm running on a meat brain substrate; five things, plus or minus
two, on a good day. I can keep track of the giraffe but once there are
more than seven I cannot hope to keep track of them all.

(And yes, this is variable by people and "good day" and so on, but for
everyone there comes a point at which it collapses into "all god's
creatures".)

So I can't know how the semantic rules interact in the general case; I
can approximate it variously well for some variable subset.

Desirable ~syntax rules keep this problem from being worse than it must.
(E.g., no comment node will ever show up in the string value of an
element; the element string property is defined so that I don't have to
think about anything that isn't a text node. That's more data than
syntax but it still helps keep things from becoming needlessly
complicated.)

I don't have any pellucid clarity about ixml pragmas to offer, just a
sense that the combination of completely free-form semantic meaning and
an expectation that everyone does not construct the divide between
syntax and semantics in exactly the same way is going to produce
undesirable variability.

[snip]
> Now, we're talking as though there are going to be hundreds of
> pragmas, all vying for attention. In reality, I think that's very
> unlikely. So working out how the pragmas will interact with each other
> isn't likely to be terribly complicated. 

More flavours of magic comment containing content than element names,
more processing instruction names than element names for PIs used to
store content, use of processing instructions to allow non-nested
hierarchies of content (it was meant to be a workaround for "that
element isn't valid there"), and putting a few hundred lines of JSON in
attributes ought to be unlikely, too, indeed I am pretty sure they ARE
unlikely, but I've encountered all of them at scale in production
environments.

If it's possible, it'll happen, and combinatorial explosions increase
factorially. It doesn't take hundreds, it takes four to stop being
comprehensible to mortals. Ten is a plenitude to remove any possibility
of comprehension by inspection and understanding.

"This needs to run on any of three processors because corporate rules
about avoiding software dependency" and four pragmas per processor and a
little bit of mutual interoperability of pragmas across processors is
more than enough to get to "all god's creatures".

That might not be fixable, but it sure feels nervous-making.

> But I absolutely don't accept that you will ever be "unable to know
> which pragmas actually have an effect". You won't know simply from the
> pragma's location in the grammar; you will know because you won't use
> a pragma without having understood its semantics.

In a production environment, more than half the time, I didn't write the
grammar; I got handed the grammar. "You're maintaining this now, please
get that bug fixed for tomorrow."

The project phase at my former employer that involved an ixml grammar
has notionally completed, but the project has not. Should that client
insist on a change, someone who has had nothing to do with ixml, didn't
make any of the decisions related to it, and who didn't spend the
couple-three months building the specific grammar being used, will be
handed just that scenario. This is far more common in production
environments than getting to solve the problem yourself from the
beginning.

[snip]
> > A pragma requirement to the effect that any processor which supports
> > pragmas must be able to produce a version of the input grammar
> > containing only those pragmas which will be processed would be
> > welcome. 
> 
> I agree, but I think it's a quality-of-implementation issue. 

There is a level of quality of implementation below which the
implementation isn't reliable.

Nor will any implementation be perfect; not being able to find out which
pragmas are really being processed, irrespective of which pragmas OUGHT
to be processed, strikes me as falling below that level of reliability.
(Especially as my, or anyone's, notion of "ought" can easily be in
error.)

Which would, to me, make it a reasonable basis for a general constraint.

[snip]
> > But it doesn't seem like a good idea to accept stacking barriers to
> > adoption higher than they are, either.
> 
> I think it's very important to remember that using pragmas in your
> grammars will be entirely optional. If you find that they complicate
> your workflow, there's absolutely no reason you should use them. They
> will only add complexities for implementers, and for authors who
> choose to use them.

I think it's very important to remember that in a production
environment, none of that is true. They're not going to be my grammars;
there will be a coding standard, there will be already-written grammars
too complex to even consider replacing, and if certain pragmas are
expected or required by either of those things I am going to have to use
them. (There are probably also colleagues of various skill levels
responsible for the accumulation of changes in the grammar as I receive
it, even if there are not (as there probably shall be) colleagues
responsible for making changes to it during the same span of time I am
expected to do so.)

I would further argue that it's important to remember that the
reputation and mind share of ixml will be substantially created by
people to whom ixml is a thing that happened, not a thing they sought
out.

-- Graydon


--  
Graydon Saunders  | graydonish@fastmail.com
Þæs oferéode, ðisses swá mæg.
-- Deor  ("That passed, so may this.")

Received on Monday, 17 February 2025 22:58:18 UTC