Thomas Lord scripsit:
> At the same time, the excuse "because it contradicts Unicode
> best practices" is not, in and of itself, sufficient reason to assign
> any source text an error meaning. That is, implementations should
> be permitted to assign such source texts a non-error meaning.
Section 3 says:
An implementation is not permitted to extend the lexical or read
syntax in any way, with one exception: it need not treat the
syntax #!<identifier>, for any <identifier> (see section 3.2.3)
that is not r6rs, as a syntax violation, and it may use specific
#!-prefixed identifiers as flags indicating that subsequent
input contains extensions to the standard lexical syntax.
Since the characters under dispute are not derivable from any production
in Chapter 3 (other than the <character> and <string element> productions),
they are forbidden in conforming R6RS programs, and conforming R6RS
implementations must reject them (though nothing prevents a given
implementation from providing one or more modes in which it does not
claim to conform to R6RS).
On your argument, the program
(let ((x 1) (y 2) (cons x y))
could be assigned a menaing by a conforming R6RS implementation.
> In general, the report must, if it is to remain true to its preamble, aim
> to define a least upper bound of constraints on implementations.
Such is not the view, evidently, of the editorial committee.
--
John Cowan http://ccil.org/~cowan cowan_at_ccil.org
'Tis the Linux rebellion / Let coders take their place,
The Linux-nationale / Shall Microsoft outpace,
We can write better programs / Our CPUs won't stall,
So raise the penguin banner of / The Linux-nationale. --Greg Baker
Received on Fri Dec 01 2006 - 19:10:43 UTC