Am Mo., 26. Juli 2021 um 15:37 Uhr schrieb Marc Nieper-Wißkirchen < [email protected]>:
> Am Mo., 26. Juli 2021 um 15:14 Uhr schrieb John Cowan <[email protected]>: > >> >> On Mon, Jul 26, 2021 at 8:09 AM Marc Nieper-Wißkirchen < >> [email protected]> wrote: >> >> >>> SRFIs normally give a user-directed specification of what these things >>>> do, and put the implementation strategy into the non-normative >>>> "Implementation" section. This SRFI is almost all implementation strategy. >>>> >>> >>> Can you clarify what you mean? I don't think I say anything about how to >>> implement these things. >>> >> >> The idea of quasi syntax objects is a brilliant way of discussing both >> syntax-case and ER macros with a common vocabulary. But unless it is your >> claim that they are the *only* way to correctly implement ER (in which case >> the implementation merges with the specification), then I don't see how >> passages like the following can be interpreted except as (broadly drawn) >> implementation specifications: >> >> At first, the input form is recursively fully unwrapped preserving any >>> shared or cyclic structure. Then proc is called with three arguments, >>> the fully unwrapped input form and two procedures rename and compare. >>> It is an error if it does not return a quasi-syntax object. The symbols at >>> the leaves of the quasi-syntax object returned are then replaced by their >>> injections to yield the output form as a syntax object. >> >> > Doesn't look operational semantics always this way? I don't care how, say, > er-macro-transformer is implemented as long as it behaves operationally > equivalent. > > To give one example outside SRFI 225: If you take a look at 12.1 of the > R6RS Standard Libraries, the expansion algorithm is operationally described > through Dybvig's marks and substitutions algorithm. While the R6RS expander > can be implemented in this way (Chez Scheme, psyntax, Unsyntax) by directly > transforming the semantics into an algorithm, it doesn't have to be > (Larceny, Chibi Scheme). > > Also, note that the predicates of being "wrapped" and "unwrapped" syntax > objects have to fulfill some axioms but they are not fully defined in the > sense that they allow only one model. For example, in some implementations > "fully unwrapped" syntax objects can be just the same as "wrapped" syntax > objects. > I have added a note clarifying that this SRFI does not mandate a particular way of implementing the macro facilities. > > >> By the way, I think the use of `quasisyntax` from R7RS as an analogue of >> quasiquote and the term "quasi-syntax objects" are unrelated, and if so, >> distinguishing them solely by a hyphen is a mistake. >> > > Yes, that's not ideal. Do you have a better prefix to name "almost syntax > objects" in mind? > I have renamed "quasi-syntax" to "presyntax" and "quasi-identifier" to "preidentifier", accordingly. Both the above changes are already in my private repo, accessible through the latest official draft. Marc
