[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
JINX,
Some general comments on your general comments:
--------
Some general comments on your proposal:
1) We certainly need most of the functionality you have suggested.
I am happy that someone else thinks so.
2) I think it's premature to standardize on something like this for
IEEE. Proposals along these lines should certainly be considered for
R5RS.
On the contrary, we need to standardize library issues as soon as
possible to keep divergence from preventing portability. The IEEE
standard is a good place for this. I really would rather see only
*language* issues in RnRS. Most languages standardize too late--after
implementations have significantly diverged--and there is hell to pay as
each implementor tries to get *his* dialect as *the* standard (e.g.
ATLAS). Currently, we have a portable language, but not portable code.
I believe that there is sufficient practical experience to have a
standard interface to common functionality and that the IEEE standard
needs such an interface to be viable.
Comments on individual issues:
1) IMPLEMENTATION-INFORMATION: I'd much rather see strings returned.
They are unlikely to be used often, so the extra time spent in the
comparison should not be important. The analogous MIT Scheme
procedure returns a vector of strings and numbers.
A vector is fine by me. Strings and exact integers are fine by me. Anyone?
Why is SCHEME-IMPLEMENTATION needed, given IMPLEMENTATION-INFORMATION?
I am happy to flush this.
2) FORMAT: I assume you mean the current OUTPUT port when <port> is #t,
rather than the current INPUT port. I don't mind FORMAT, but I think
that Chris Hanson has some objections to it, which is why MIT Scheme
has flip-flopped between having it and not.
Yes, I do mean OUTPUT port (I am sure typo's abound). Given string
ports, FORMAT is easy to implement and very useful. Chris?
3) PRETTY-PRINT: I would like to extend it in the following way: If
<sexp> is a procedure object rather than a Sexp, it's source code (or
suitable substitute if compiled and source is not available) is
printed instead.
Fine.
4) RESET and FATAL-ERROR: I would propose a different, more powerful,
procedure instead, on top of which both of these could easily be
built.
(ABORT-TO-NEAREST-REPL <thunk>)
fetches a continuation created by the nearest repl (nearest in systems where
there is more than one, like MIT Scheme, the top level one if there is
only one) and executes <thunk> with this continuation.
Thus
(define (reset)
(abort-to-nearest-repl (lambda () unspecific)))
(define (fatal-error message . irritants)
(abort-to-nearest-repl
(lambda ()
(for-each (lambda (unused-arg)
(display #\space)
(display obj))
(apply format #t message irritants))
(newline))))
How is the "nearest repl" known to the runtime system? How does a
Scheme system recognize that a function is a (possibly user written)
repl? I don't have a problem with implementing RESET or FATAL-ERROR
this way, but why standardize this function as a library routine?
I have strong objections against having a procedure named FATAL-ERROR
(or anything else with ERROR in it's name) which does not allow the
option of fixing the bug and proceeding.
Perhaps I'm confused. You don't want a FATAL ERROR to abort a
computation? This might be a valuable behavior in a (possibly
parallel) multi-tasking search situation. What would be the
difference between FATAL-ERROR and ERROR ? The thing that I am trying
to clean up here is the confusion over CERROR vs ERROR as to when an
error is fatal and when recoverable. `ERROR' is pretty common and
typing RECOVERABLE-ERROR gets a bit tedious.
I'm not too attached to the name ABORT-TO-NEAREST-REPL. The similar
MIT Scheme procedure is called ABORT->NEAREST.
I don't see this as a common usage in other Scheme implementations.
Anyone?
5) ERROR must be a special form in order to get the environment of
the "call". In MIT Scheme, the ERROR special form expands into
something like
(ERROR-PROCEDURE (the-environment) <message> . <irritants>)
ERROR works just fine as a procedure in many systems (Chez Scheme, T,
and MacScheme). The fact that MIT Scheme has a non-standard way to
access the environment makes it convenient for ERROR to be a special
form in MIT Scheme. I would really prefer that you propose an
standard environment mechanism if you want to insist that ERROR must
be a special form (or better yet, a standard error handling
mechanism). I really prefer procedures to special forms.
How much code would break if I change the wording to allow ERROR to be a
procedure *or* a special form?
6) TRACE and UNTRACE: Do you want identifiers or procedure objects?
If you want procedure objects you are forcing implementations to make
them modifiable.
If you want identifiers you must make TRACE and UNTRACE special forms
so they can get the environment of the "call" and therefore alter the
correct bindings.
These are procedures in MacScheme and PCScheme and special forms in
Chez Scheme and T. PCScheme, T, and MacScheme all require procedure
objects rather than procedure names. I will change the wording to
indicate this and allow TRACE and UNTRACE to be either procedures or
special forms.
7) ALIAS: Why can't you just use (define <alias> <original>) ?
This is hard to do with special forms.
A different question is making your compiler generate reasonable code,
but this should not be difficult.
If you want to use it for special forms instead (like comment), I'd
rather wait until we have some way of creating syntactic extensions.
The reason for these bits of syntax is that we need to solve the
portability problems now and we do not yet have syntactic extensions.
Unless someone in Indiana moves fast, we will not have syntactic
extensions in R4RS. When we get syntactic extensions, these are easy
to `define'. I strongly suspect that the number of Scheme
implementations is going to double every year or two for a while. We
need to be heading off the problems that will exist in 5 years unless
fixed now.
8) COMMENT: I think you want to divorce the issues of reading and
ignoring a form. Maybe it's just a bug in your specification, but I'm
not sure why you involve the reader at all.
I will elide the reference to READ.
9) UNLESS and WHEN: I would wait for syntactic extensions. I
generally object to adding spurious special forms.
We don't have syntactic extensions. I see these in a lot of code. I
believe they are common usage. Who else out there objects to these?
Who else uses them?
10) COMMENT-WHEN: Does this imply read time or syntax time evaluation?
Again, I'd wait for macros.
I was thinking of Chez Scheme's EVAL-WHEN when I wrote this (but we
don't have EVAL!). Perhaps I should withdraw it and use Kent's
definition instead. Kent?
11) THE-CURRENT-DATE and THE-CURRENT-TIME: I assume you mean exact
integers for fixnums.
Yes.
12) string ports: I like them (and use them frequently), but I think
we should bite the bullet and have constructors and selectors for ports:
(MAKE-INPUT-PORT <char-peeker> <char-reader> <char-ready-predicate> <close>)
(WITH-INPUT-PORT-COMPONENTS <input-port>
(lambda (peek read ready? close)
<actions>))
(MAKE-OUTPUT-PORT <char-writer> <string-writer> <close>)
(WITH-OUTPUT-PORT-COMPONENTS <output-port>
(lambda (char-write string-write close)
<actions>))
String ports can easily be built on top of this, but other ports (to
editor buffers, transcripting and tee'd ports, etc) can be built as well.
I will add this, but keep string ports as a common usage.
13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.
So you want 3..258? I think that silent masking of overflow would be
pretty random.
14) BOUND?: must be a special form, since it has no way of obtaining
the environment of the "call".
I will update to be either procedure or special form.
15) DEFINE-IF-<mumble>: These make sense only at top level of a file,
but not in internal definition position, and that makes them appear
strange. I don't think that special forms like DEFINE-IF-<mumble> is
the way to conditionalize code, but this is a matter of taste.
I don't see how these differ from non-conditional defines, which also
appear strange. I would be very happy to see a better proposal on
conditional compilation.
I would also change the EQ? test to STRING=? given my comments about
IMPLEMENTATION-INFORMATION.
Yes, if this is the concensus.
16) SORT and SORT!: You probably want (SORT <obj> <binary-predicate>).
I don't know what predicate to use by default.
Yes, a <binary-predicate> is required. There is no default. Mea typola.
17) AUTOLOAD: Must be a special form like DEFINE and DEFINE-IF-<mumble>.
PCScheme has an AUTOLOAD-FROM-FILE procedure. I will have the definition
allow either a procedure or a special form.
----------
Thank you very much for your input.
-The Reader