Sam TH wrote:
> The IEEE Scheme standard does not include macros, which is precisely
> what makes the example I presented difficult. How would you propose
> to change section 5 to accomodate macros?
The obvious way is with a one-pass algorithm that assumes
any reference to an as-yet-undefined identifier is a
reference to some identifier that will later be defined
as a value (not a macro).
> Additionally, the IEEE standard supports the REPL at the cost of
> making the following program "an error"
As I explained in my earlier response to Mike Sperber,
that explicit ambiguity resulted from compromise, just
as many similar ambiguities in the R6RS resulted from
similar compromises. As a technical matter, removing
that ambiguity would be absolutely trivial.
> Would a single pass algorithm have resulting in the program I gave
> being portably exception-raising? Or would it simply be non-portable?
Both of your examples would be flat-out portable if the
semantics of R5RS section 7.2 were adopted along with
the macro semantics sketched above.
If you prefer, however, you could also design a semantics
in which one or both of your examples is non-portable, or
you could design a semantics in which one or both portably
raises an exception.
Designing a non-portable or exception-raising semantics
would be more difficult than just adopting the flat-out
portable semantics based on R5RS 7.2.
To repair the R6RS, I would suggest using the semantics
of R5RS 7.2 only for top-level programs. REPLs could
then have exactly the same syntax and semantics as
top-level programs. That would not make the semantics
any less consistent, because the syntax and semantics of
R6RS top-level programs already differ from the syntax
and semantics of R6RS libraries.
Also relevant here is the fact that, although the R6RS
requires implementations to raise exceptions for some
ambiguous situations that arise with the R6RS semantics
of macros, few implementations of the R6RS are actually
raising those exceptions [1]. Furthermore, as I had
noted in my exchange with Mike Sperber, the semantics
of macros is more ambiguous in the R6RS than in the
R5RS (primarily because syntax-case is harder to specify
than syntax-rules).
Although the R5RS semantics is indeed non-portable in
corner cases, mainly because of political compromises,
the bottom line is that:
(1) the R6RS semantics of libraries and programs is
even less portable than the R5RS semantics for
REPLs, and
(2) the R6RS semantics for REPLs is completely absent
and therefore completely non-portable.
That is not to say that R6RS programs are less portable
overall than R5RS programs. Standardization of lexical
syntax, particular libraries, and arithmetic improved
portability relative to the R5RS, and those things matter
more in practice than the kinds of things you are talking
about.
Will
[1] http://lists.r6rs.org/pipermail/r6rs-discuss/2009-February/003780.html
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
