[r6rs-discuss] Now, where were we?

[Sam TH]

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 [1]), 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?

[1] Sec 4.1.1 states "It is an error to reference an unbound
variable.", which the reference to `odd?' is in the definition of
`even?'.
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".

-- 
sam th
samth at ccs.neu.edu