[FWD for Bethan]: Re: What is a pragma?

[ Bethan’s email of earlier this afternoon ran afoul of some W3C email validation process that may include a delay of “a day or two”. She asked me to forward it before tomorrow’s call. ]

Happy New Gregorian Year, everyone! 

Now that my holiday hibernation period is coming to a close, I’ve come back to this question. I
feel that we really must come to a common understanding of what is meant by a “pragma” (aka a
"directive" or an "assertion"), in order to decide a) whether we feel that pragmas are a good
addition to the iXML standard, and b) if so, what the scope of iXML pragmas should be. 

Michael and Tom spent a lot of time and energy on these questions, in order to bring to the table a
proposal for pragmas in iXML
(https://github.com/invisibleXML/ixml/blob/proposal-pragmas/misc/pragmas.md). As I understood
it, the proposal was intended as a starting point for discussion, and was based on an
understanding of how pragmas (or analogous constructs) are defined and/or implemented in other
languages. 

I had a number of fairly robust discussions with Michael about the pragmas question, and we
worked together with Norm on a Balisage paper based on the pragmas proposal
(https://www.balisage.net/Proceedings/vol27/html/Sperberg-McQueen01/BalisageVol27-Sperberg-McQueen01.html).


The pragmas proposal failed to make it into iXML v1 because of a lack of unanimous support.
Nonetheless, the fact that the proposal was supported by the majority of the Community Group's
active members at the time gives me some hope that it can be a useful basis for a new discussion
on adding pragmas to iXML vNext. 

So, in an effort to give us a solid foundation for discussion, I will list features of pragmas
which I believe can be derived from prior literature. I’ve separated these features into two
categories: essential features, which are required to define a pragma as commonly understood;
and accidental features, which characterize many pragmas, but whose absence does not preclude
defining a construct as a pragma.

(The list of features is synthesized from the publications in the brief bibliography at the end of
this message. The bibliography is numbered, so that direct quotations can be easily atttributed.)

a) Essential Features

* a pragma is a syntactic construct defined by the grammar of a language;
* a pragma is embedded in source code;
* a pragma conveys information to processing software (such as a compiler or processor);
* a pragma which cannot be interpreted at runtime because it is not recognized by the processing
 software (rather than e.g. because it is ill-formed), must be ignored;
* removing/ignoring all pragmas should not affect the syntactic validity of the code.

b) Accidental Features 

* in many cases, "what works on one compiler almost certainly won’t work on another" [2] - a
 pragma might only be recognized by a single implementation; alternatively, different
 implementations may recognize the same pragma, but respond to it in different ways;
* a pragma should usually not change the semantics of the code;
* a pragma may, nonetheless, change the effect produced by running the program ("'semantics' is
 not the same as 'effect'; [...] The semantics defines a set of possible effects" [4], so some
 language specifications permit code to produce certain different effects when a pragma is
 recognized, without considering this a change in semantics. Changes to internal effects are not
 considered as changes in semantics, provided that they culminate in "an appropriate sequence of
 external effects" (such as outputs, results, or exceptions) [4].);
* a pragma may give "an instruction or [a] suggestion" - that is, when a pragma is recognized,
 it may or may not be mandatory that the processor respond to the information it conveys;
* pragmas are usually used to convey information which cannot otherwise be conveyed by the
 standard syntax of the programming language (although, in theory, there is not usually a
 prohibition on using a pragma to convey something that could alternatively be conveyed using the
 standard syntax) [5].

If anyone has anything to add, or has amendments to suggest, I'd value your input. I propose that
we should come to a consensus of what we mean by a pragma before we discuss any of the other
issues related to pragmas in iXML, since the discussion up to this point has often been going
around in circles because we can't agree on a definition.

Very best,

Bethan

Bibliography

[1] 1989 Grogono, P, "Comments, assertions, and pragmas", SIGPLAN Notices 24.

[2] 1995 Chisholm, P S R, et al., C Programming: just the FAQs

[3] 2006 Van Weert, P, et al. "To CHR or not to CHR: Extending CHR with negation as absence",
K. U. Leuven Report CW 446

[4] 2022 Annotated Ada reference manual: 2022 edition
(https://www.adaic.org/ada-resources/standards/ada22/)

[5] 2022 Hillman, T, et al., "Designing for change: Pragmas in Invisible XML as an extensibility
mechanism"
(https://www.balisage.net/Proceedings/vol27/html/Sperberg-McQueen01/BalisageVol27-Sperberg-McQueen01.html)


___________________________________________________ 
Dr. Bethan Tovey-Walsh 

linguacelta.com

Golygydd | Editor geirfan.cymru

Croeso i chi ysgrifennu ataf yn y Gymraeg.

 On 10 Dec 2024, at 15:59, Norm Tovey-Walsh <norm@saxonica.com> wrote:

 Near the end of today’s call, I believe there was some disagreement about whether or not what
 the Balisage proposal for pragmas in iXML described was, or was not, “a pragma”. I humbly
 point to the Wikipedia page on “Directive (programming)” which is where you get to if you try
 to find pragma.

 I believe the breadth and depth of what is already viewed by the community as “a pragama”
 speaks for itself.

  https://en.wikipedia.org/wiki/Directive_(programming)

                                        Be seeing you,
                                          norm

 --
 Norm Tovey-Walsh
 Saxonica

Received on Monday, 6 January 2025 21:42:52 UTC