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

Re: null-environment inconsistency in core.tex.gz

   From: Kent Pitman <kmp@harlequin.com>
   Date: Mon, 9 Feb 98 17:34:11 EST
   To: dyb@cs.indiana.edu
   Cc: kelsey@research.nj.nec.com, rrrs-authors@martigny.ai.mit.edu
   Subject: null-environment inconsistency in core.tex.gz
      Date: Mon, 9 Feb 1998 17:14:43 -0500 (EST)
      From: "R. Kent Dybvig" <dyb@cs.indiana.edu>
      >    In the EVAL example, null-environment is called without arguments.
      >    Yet the \proto line for null-environment specifies a `version'
      >    argument.
      > The prototype is wrong.  NULL-ENVIRONMENT takes no arguments.
      > Thanks for pointing this out.
      I thought we had decided that null-environment must take a version
      argument, since the set of syntactic forms defined in the environment
      specified by the return value of null-environment depends upon the
      report version.
   Even in the report versions where null-environment does not occur? Hmm...
   And do the bound operators all have their semantics from back then?  Like
   if I want to have #f and () be eq?  ... What fun.  I hope 0 and negative
   numbers can be specified to get the pre-revised reports.  Fun with CATCH
   and FLUID. Hmm...
   Also, what about the Revised report itself?  Since it was not revised^n,
   is n=1 a valid value of null-environment.
   I'm so excited by all this.  It's going to do wonders for CL's marketing
   when Scheme images are bigger than CL images because they have to hold all
   of history in null-environment (what an ironic name, since it will have 5
   times as much environment in it as the initial environment does)...

This is not new technology; if memory serves me correctly,
DEC PDP-10 TECO had a command (EO ?) that took a version number
as an argument and caused the TECO to behave as of that version number.

(I have just tried to verify this, but the only DEC PDP-10 TECO manual
I can find is from 1968, which is too early.)