[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slimming down SRFI 107

This page is part of the web mail archives of SRFI 107 from before July 7th, 2015. The new archives for SRFI 107 contain all messages, not just those from before July 7th, 2015.



Per Bothner scripsit:

> Let me summarize what I think you're saying: This SRFI should be purely
> about the reader extension: The syntax, and how it is translated at
> read-time to normal S-expressions.  The semantics of those S-expressions
> (i.e. how they are actually evaluated) should not be specified, but
> could be a separate SRFI.

That is the main thrust of what I am saying, yes.  But even if you choose
to keep the (partial) semantics in the draft, I do strongly believe
that they need to be carefully separated from the syntax.  The current
discussion flips between its three goals in a very confusing way.
Of course, putting the semantics into a separate SRFI is an extreme
version of this separation.

> First, I believe the semantics provide a rationale for the syntax and
> the translation, in providing at least one "natural" implementation
> that supports fairly complete XML semantics within Scheme programs.

My view is that XML is self-justifying except among people who detest it,
who probably cannot be convinced of its merit by any argument available
to us.

> Second, I have tried to keep the semantics fairly flexible, supporting
> different embeddings and implementation strategies.  Are there valuable
> semantics that are inconsistent with the draft?

I don't know, but (as I have been posting elsewhere today), I believe
that there might be, and an implementation of this SRFI should not
necessarily inhibit them.  One of the minor reasons that I prefer Scheme
to Common Lisp is that Scheme provides an explicit S-expression syntax
for quasiquotation, which means that its parts can be repurposed.
For example, the Scheme48 and Chicken interpreters express commands as
,foo = (unquote foo).  This could not be done in Common Lisp, where comma
not within a backquote is a (lexical) syntax error in all implementations
known to me.

> One possible issue is that I've focused on XML constructors in Scheme
> *programs*, and not as raw data in files.  Standalone data use isn't
> precluded by the SRFI, but such usage might not be interested in
> the semantics.

Indeed.  And of course what can appear in a data file can also appear in
a quoted object inside a program, to be dissected in some non-standard
way by that program.

-- 
Do I contradict myself?                         John Cowan
Very well then, I contradict myself.            cowan@xxxxxxxx
I am large, I contain multitudes.               http://www.ccil.org/~cowan
        --Walt Whitman, Leaves of Grass