[r6rs-discuss] comment and vote (if allowed)

From: Elf <elf>
Date: Tue, 21 Aug 2007 04:19:16 -0700 (PDT)

On Tue, 21 Aug 2007, Keith Wright wrote:

>> From: Elf <elf at ephemeral.net>
>>
>> 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?)

A quick browse through where SICP code will break (using v2 of SICP):
1.1.4, compound procedures. explanation of compound vs primitive procedures,
pg 13.
1.1.7, newtons method. sqrt redefined, pg 24. possibly different float
semantics, pg 24, as well as in exercise 1.7, pg 25.
1.2.1, linear recursion and iteration. + redefined, exercise 1.9, pg 36.
1.2.4, exponentiation. expt redefined, pg 44-45. even? redefined, pg 45.
* redefined, exercise 1.17, pg 46.
1.2.5, greatest common divisors. gcd redefined, pg 48-49.
1.3.3, procedures as general methods. sqrt redefined, pg 69.
1.3.4, procedures as returned values, sqrt redefined, pg 73, pg 75, pg 76.
2.1.3, what is meant by data?. entire section. pgs 90-93.
2.2.1, representing sequences. entire section, particularly pgs 101-103.

im stopping here because i dont want to be typing a table of contents, and
continuing to list where SICP breaks would become a table of contents after
that point, at least for chapter 2 and much of 3. the immutability of imports
robs SICP of explanation, demonstration, and concept of building complex
procedures from basic building blocks.

>> (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.

the given code was in terms of r5rs + srfi-57. it was intended as a
demonstration of what immutability breaks. in plain english, without violating
the immutability constraint, it is impossible to add any checking or
modification of values passed to field-mutator procedures before actually
performing the mutation. apologies if the code given was in an unfamiliar
format.

>
>> which is incredibly useful for, say, using records as structs in an ffi,
>
> No Report has any ffi.

i was in no way claiming that any report explicitly details an ffi (although
certain aspects of r6rs come close in some ways). i was merely giving an
example of something i play with. the ability to add value checking to
field mutators is something i find useful in a general sense. constraining
permissible values before theyre set makes threading cleaner, simplifies all
other procedures operating on the record, aids debugging, etc.
>
>> 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)

"load FILENAME
     FILENAME should be a string naming an existing file containing Scheme
     source code. The 'load' procedure reads expressions and definitions
     from the file and evaluates them sequentially. It is unspecified
     whether the results of the expressions are printed. The 'load' procedure
     does not affect the values returned by 'current-input-port' and
     'current-output-port'. 'load' returns an unspecified value.
         Rationale: for portability, 'load' must operate on source files.
         Its operation on other kinds of files necessarily varies among
         implementations."
              -- R5RS

perhaps i am stupid here, but what 'load' does seems very clear to me.
(expressions and definitions are previously defined in sections 4 and 5.)
i dont know how much more detail is required before the semantics of load
are considered clear, but i will note again that in every implementation
i've used, load has worked precisely the same on source files. (there is
one exception to this, actually. lispme for palm handles load differently
due to not having separate source files. however, the code as a memo still
works the same.) the REPL is not called 'REPL' but is explicitly mentioned
in R5RS in the explanation/rationale for call-with-current-continuation and
interaction-environment. i find the top-level program explanation in r6rs
to be a less-clearly-worded version of section 5 of r5rs with an added
'import' construct.


>
> 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.
>

heh. im running a heavily-hacked version of scwm (guile) as my window manager.
most of my general-sysadmin scripts are in scsh or gauche. most professional
and recreational code is in guile, gauche, s48, or chicken, depending on
when, where, and why i wrote it. my primary implementation-of-choice atm is
chicken. rscheme ive not worked with extensively but have been looking at
for SLAM kernels. and, of course, legacy code was written in mit-scheme. i
have not used chez (no money) or plt (hate the interface) directly, though
ive looked at many plt library implementations. point being only that i am
acutely aware of the differences between the r4 and r5 reports, and the layers
that each implementation adds on top. imho, the easiest way to resolve
portability issues would be to simply add an efficient source (and potentially
binary) module system. r5rs already separates between interaction env and
r5rs env. i am probably wrong, but it does not seem like it would be difficult
for each implementation to create a module/lib (or set thereof) of what it
considers the interaction env, and with a standard module system in place,
it becomes trivial then to load code for a separate implementation simply by
including that implementation's interaction-env-library module. on a related
note, instead of adding oodles of extra syntax to allow hygenic macros to be
partially unhygenic (or to resolve data, or ... ), merely allowing 'traditional'macros (define-macro) as well as hygenic (define-syntax) should be equivalent
but clearer.


-elf
Received on Tue Aug 21 2007 - 07:19:16 UTC