[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Portability (long)
(ABORT-TO-NEAREST-REPL <thunk>)
...
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?
The idea is that the runtime system provides facilities for building
repls which interact with these abort procedures (there are many in
MIT Scheme), and can provide additional functionality. While this
procedure is useful for writing things like RESET, it is useful in its
own right: interrupt characters cause invocations of such procedures
in MIT Scheme. Dan Friedman needs something like
ABORT-TO-NEAREST-REPL for some of the stuff he does as well.
My recollection is that Dan wants a global variable bound to the
continuation caught at the top level. Most implementations have a RESET
function now. Describing RESET library interface describes what is
typically there now. Adding ABORT-TO-NEAREST-REPL to the library
interface (given the things that are missing) is, I feel, premature.
ABORT-TO-NEAREST-REPL is a proposal for RnRS.
**********************************************************
Currently there are error functions defined with 2 different behaviors.
One acts like
(define (ERROR msg . args) (format #t message args) (reset)).
The other acts like
(define (ERROR msg . args) (format #t message args) (debug)).
Different Scheme implementrations supply one form or both forms and both
forms are called ERROR by some implementations. I called the first one
FATAL-ERROR and the second one ERROR. Perhaps I should have just used
the MacScheme convention (ERROR and CERROR). I would like a consistent
naming convention across implementations which distinguishes behavior.
Please propose one (How about NOISY-RESET and ERROR?).
**************************************************************
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.
I'm very confused. As far as I know, all correct scheme
implementations must be properly tail recursive, and this is what forces
error to be a special form. For example, in ...
ERROR *is* a procedure in Chez Scheme, T, and MacScheme. Yes, tail
recursion loses in the cases you mention. I understand the
implementation considerations. I will not propose that those who
implement ERROR as a function be forced to change that implementation to
be a special form. You are free to convince them.
************************************************************************
Yes, TRACE was underspecified. TRACE and UNTRACE should take values.
(I said that).
************************************************************************
7) ALIAS: Why can't you just use (define <alias> <original>) ?
This is hard to do with special forms.
...
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.
...
Although I agree with the gist of your argument, I don't see how this
applies to ALIAS. Either you have a special form in the first place
which you are providing an alias for, or you do not. If you have it,
you can use the original. If you don't, ALIAS won't solve your
problem: In order for ALIAS to be of any help in portability, you need
conditional compilation or conditional loading according to
implementation. Whatever you use to discriminate according to
implementation, you can use to provide definitions of the "missing"
special forms using each implementation's syntactic extension
facilities. As far as I know, all implementations have ways of
providing syntactic extensions.
ALIAS is useful in porting code and exists in current implementations
(PCScheme, Scheme-84). Yes, all implementation have ways of providing
syntactic extensions. The problem is that few of them are the same
(macro, define-macro, define-syntax, extend-syntax, ...). I can't write
ALIAS portably.
*************************************************************************
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.
I meant that 8 bit bytes are pretty arbitrary. It would be nice to be
able to read in (for example) 16 bit quantities, 32 bit quantities,
etc. Furthermore, although rare, there are still machines around that
are not based on 8 bit bytes, and they may become popular again in the
future. I would hate to see current hardware praxis getting into
the language.
Yes, it would be nice to stay out of port and register sizes. It makes
writing system code somewhat difficult, however. Are you proposing a
parameterized routine? e.g. (WRITE-BINARY <exact-integer> . <num-bits>)?
I think that this special case of binary-i/o is helpful. The general
case is hard to specify well.
**********************************************************************
...
BOUND? may be a primitive procedure which accesses the environment of the
call via agreement between the compiler and runtime system. Isn't
requiring it to be a special form overspecification? I think that we
could really make do with BOUND-AT-TOP-LEVEL? or some such. I think
it best to flush DEFINE-IF-<mumble>, but testing for existance of a
definition without generating a runtime error is a necessity.
**********************************************************************
Unless there are strong objections I will flush DEFINE-IF-<mumble>.
************
I have only heard from 3 people and would appreciate more opinions and
comments.
Thanks,
-Ken kend@mrloog.LA.TEK.COM