> From: Elf <[EMAIL PROTECTED]> > > I was unable to register for the voting process due to a > set of computer failures on my end. I realise that this > vote is invalid, but I wanted to bring up a few things.
I did not register because I do not feel qualified to vote. In any case, I am not sure I care all that much what the Report says, so long as it says something. If I want to write a program I will write it to be evaluated by whatever implementation is available. If I want to implement a Scheme compiler/interpreter it will be because I want to try a new idea which won't be in the Report (because its a new idea) and so I will ignore the Report. I do not expect the police to stop me. Nevertheless, I have already made a few comments on this list, because I do want to understand the Report, and I do want the Report to actually say what the editors want it to say (i.e. to be free of typos and thinkos). > Scheme is a beautiful language, and books like SICP can > help them appreciate that... but with R6RS, many of the > exercises will no longer work. Do you have a specific example of this? If true, it would be a very serious problem, but as I recall, SICP does not make use of much beyond the base language. I think the part of Scheme that occurs in SICP has not changed much. In particular, SICP does not use macros, so the addition of macros (which, by the way, have been there in some form for at least the last three Revisions of the Report), or changes to the way macros work, can not break anything in SICP. (Am I wrong?) > (define-record-type foo (make-foo a) foo? > (a foo-a foo-a-set!)) R6RS (if I may now call it that) contains a definition of the identifier define-record-type, but this seems to be a syntax violation if interpretted as specified there. I am not aware of any previous revision of the report that includes any definition at all for this identifier. I am unable to parse your program, and therefore unable to decide if I agree with your criticism. > which is incredibly useful for, say, using records as structs in an ffi, No Report has any ffi. > The removal of "load" and of almost all REPL functionality > is even more absurd. I do not think there is anything in R6RS that forbids an implementor from putting in a "load" procedure and a REPL, if that makes sense in the context of the implementation and its goals. Previous Reports did mention "load" but it was never quite clear exactly what it did. Previous Reports did not mention a REPL at all. If anything, R6RS does a better job than previous reports in specififying the semantics of the top level. (IMSO) It seems to me that you have a favorite implementation, and believe that more of you favorite implementation is in the previous Report than actually is there. -- Keith _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
