[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Portability (long)



    My recollection is that Dan wants a global variable bound to the
    continuation caught at the top level. 

That is pretty much what ABORT-TO-NEAREST-REPL is, except that instead
of having the REPL do

(call-with-current-continuation
  (lambda (here)
    (fluid-let ((RESET here))
      <code of repl>)))

it is done with (note extra parens)

((call-with-current-continuation
  (lambda (here)
    (fluid-let ((ABORT-TO-NEAREST-REPL here))
      (let ((val <code of repl>))
        (lambda () val))))))

so that the thunk will be executed when "fed" to ABORT-TO-NEAREST-REPL.

Maybe the name is confusing, so let's propose a compromise:

RESET is a procedure of 0 or 1 arguments.  When invoked with no
arguments, it does what you want.  When invoked with 1 argument, it
"resets" to the read eval print loop, and within this context, it
invokes its argument, which is what ABORT-TO-NEAREST-REPL does.

					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.

Having ABORT-TO-NEAREST-REPL (under whatever name) makes zero-argument
RESET unnecessary, and I find zero-argument RESET distasteful.

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

The ERROR special form in MIT Scheme does neither.  In the absence of
any condition handlers, it opens up a NEW read eval print loop in the
environment of the error.  The debugger can be invoked from there, or
a procedure can be invoked to abort to the previous read eval print
loop.  In spirit it is more like the second, but does not really fit.

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

I understand this.  I don't object to the name FATAL-ERROR only, I
object to the concept.  I don't believe there are such beasts as
non-recoverable errors.  I think ERROR should imply recovery, and I
will object to standardizing on anything else.  Although the
"functionality" of your FATAL-ERROR can be built on top of RESET, or
ABORT-TO-NEAREST-REPL, I don't think that users should be encouraged
to write programs that randomly abort rather than let the user examine
their state and proceed the computation after fixing whatever is
wrong.

****************************************

    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.  

I still find your argument circular.  Please give me an example where
ALIAS solves anything by itself, ie. without any conditionalization.

****************************************

    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.

I'd much rather go for WRITE-BINARY than for WRITE-BYTE.

****************************************

    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?  

Therefore you would have

(let ((foo 3))
  (bound? 'foo))

return #T

but

(define (check name)
  (bound? name))

and separately compiled

(let ((foo 3))
  (check? 'foo))

return #F?  I don't believe you are really proposing this.  This
violates all forms of referential transparency that I can think of.


							I think that we
    could really make do with BOUND-AT-TOP-LEVEL? or some such.  

Assuming we can all get to agree on what "top-level" means.


								I think
    it best to flush DEFINE-IF-<mumble>, but testing for existance of a
    definition without generating a runtime error is a necessity.

I don't disagree for the need for BOUND?.  I just object to a
procedural definition which does not make sense.