On Mon, Feb 23, 2009 at 10:07 AM, William D Clinger <[email protected]> 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 [email protected] _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
