[r6rs-discuss] Now, where were we?
samth at ccs.neu.edu
Mon Feb 23 10:55:35 EST 2009
On Mon, Feb 23, 2009 at 10:07 AM, William D Clinger <will at ccs.neu.edu> wrote:
> Sam TH quoting Andrew Reilly:
>> > What I don't understand is why having some nicely defined
>> > meaning for "finished" programs should preclude a useful
>> > semantics for "work-in-progress" programs (REPL). Can't we have
>> > both? Please?
>> The trouble is that it's hard to give them consistent semantics.
> No, it isn't hard. For example, IEEE Standard 1178-1990
> defines a semantics that can be implemented consistently
> for both "finished" programs and REPLs.
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?
Additionally, the IEEE standard supports the REPL at the cost of
making the following program "an error" (in the technical sense, at
least on some implementations ), rather than giving it a semantics:
(define (even? x) (or (zero? x) (odd? (- x 1))))
(define (odd? x) (and (not (zero? x)) (even? (- x 1))))
> The R6RS semantics, as I have repeatedly pointed out and
> as Sam's example also demonstrates, is incompatible with
> REPLs. Sam's example points out that the R6RS semantics
> for macro expansion requires two separate passes over a
> top-level program or library. The R6RS did not have to
> require a two-pass algorithm, but that's what it did.
> Hence the problem.
Would a single pass algorithm have resulting in the program I gave
being portably exception-raising? Or would it simply be non-portable?
 Sec 4.1.1 states "It is an error to reference an unbound
variable.", which the reference to `odd?' is in the definition of
Unless, of course, the implementation has followed the suggestion of
Sec 5.2.1: "It is permissible for an implementation to use an initial
environment in which all possible variables are bound to locations,
most of which contain undefined values.". However, since this is just
a suggestion, it is obviously not portable to rely upon it.
Therefore, it is in fact unspecified by IEEE 1178 whether the program
in this message is "an error".
samth at ccs.neu.edu
More information about the r6rs-discuss