Re: what I learned from today's discussion of delimiters

Dave Pawson writes:

> On Wed, 26 Jan 2022 at 04:27, C. M. Sperberg-McQueen
> <cmsmcq@blackmesatech.com> wrote:

>> We mentioned briefly today the idea that a processor that does not
>> implement any pragmas could work internally with a modified version of
>> the ixml grammar that did treat pragmas as a kind of comment.  This idea
>> does not, I think, stand up under closer examination.  To the extent
>> that pragmas have any internal structure, any conforming processor must
>> check that internal structure, since our spec requires that
>> nonconforming grammars be rejected.  To the extent that pragmas have no
>> internal structure, or a very simple one, the gain in simplicity from
>> using a modified grammar would be negligeable.

> A processor writer that does not implement pragmas.
> MSM states that he/she must check the internal structure?
>   I would hope that the implementation might simply seek the matching delimiter
> (nesting assumed).

>  Is this what you mean by 'checking the internal structure' Michael?

It is part of what I mean but not necessarily all of it.

If and when we integrate pragmas into the ixml spec, there will be rules
in the ixml specification grammar defining a set of strings (or, if you
prefer, saying what strings count as pragmas and what strings don't).
There may be prose stipulating additional constraints.  In all proposals
made so far, the grammatical structure is very modest, but not wholly
absent: the TM proposal specifies that between the opening and closing
delimiter a pragma consists of a QName and optionally additional data
separated from the QName by a whitespace character, and the SM
(strawman) proposal specifies that there must be at least one blank in
the pragma, and that after that blank there must be a sequence of
comments, pragmas, and non-brace characters.

The spec currently says that conforming grammars must match the ixml
specification grammar and satisfy constraints expressed in the prose,
which means that either the pragmas in an input grammar follow those
rules, or the input grammar is not a conforming grammar.  It also says
that conforming processors must not acccept nonconforming grammars.
From that I infer that conforming processors must parse pragmas against
the relevant part of the ixml specification grammar and check any prose
constraints.

> If not then you're putting a lot of work (and nuisance value) on that
> implementation IMHO.

There I think our opinions diverge.  For an implementation capable of
parsing arbitrary input against arbitrary context-free grammars,
checking that an input grammar is itself grammatical is neither a lot of
work nor a nuisance.  Checking the input grammar against all parts of
the ixml grammar *except* the rules defining pragmas would be a
nuisance.


> Issue - minor.
>    I'm assuming we pick a non ASCII delimiter. In emacs, easy. What
> experience do we
> have of other editors on other OS's? How easy is it to generate a
> visible Unicode glyph
> on other editors?

I don't know.

A search for "typing unicode characters in windows" produces a long list
of sites willing to explain how to do it, but how easy users find those
methods is not something I am in a position to judge.

The last time I saw an operating system without an application called
'Character Map' or something similar was maybe 1997.  In some operating
systems (e.g. Mac OS X) it's not highly visible as a separate
application because it's a service that is always available and may be
perceived by the user as part of the keyboard mechanism.  The last time
I used Windows day to day, it was possible to type non-ASCII characters
in the Windows character set by depressing the Alt key and typing the
decimal number of the code point on the numeric keypad; I don't know how
or whether that facility has been retained or modified to support
Unicode.  (The fragments of pages I saw when I did my search tell me
it's still there and is not limited to eight-bit characters.)

> Other than this I'm happy to let others choose any such character.  I
> do like 'matching' pairs,
> so my personal preference might be guillemets for no other reason.

Since you mention guillemets, I will observe that they have one slight
complication:  if I understand correctly, in different European
typographic traditions (e.g. French and German) some nations tend to
place guillemets pointy-side out and others pointy-side in, so that in
one country the form of pragma that might feel natural would be «...»
and in another »...«

My understanding may of course be incorrect.

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

Received on Wednesday, 26 January 2022 14:12:08 UTC