[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