[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: null-environment inconsistency in core.tex.gz
From: Kent Pitman <firstname.lastname@example.org>
Date: Mon, 9 Feb 98 17:34:11 EST
Cc: email@example.com, firstname.lastname@example.org
Subject: null-environment inconsistency in core.tex.gz
Date: Mon, 9 Feb 1998 17:14:43 -0500 (EST)
From: "R. Kent Dybvig" <email@example.com>
> In the EVAL example, null-environment is called without arguments.
> Yet the \proto line for null-environment specifies a `version'
> 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
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.)