1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
\extrapart{Notes}
\todo{Perhaps this section should be made to disappear.
Can these remarks be moved somewhere else?}
\subsection*{Language changes}
\label{differences}
This section enumerates the changes that have been made to Scheme since
the ``Revised$^4$ report''~\cite{R4RS} was published.
\begin{itemize}
\item The report is now a superset of the IEEE standard for Scheme
\cite{IEEEScheme}: implementations that conform to the report will
also conform to the standard. This required the following changes:
\begin{itemize}
\item The empty list is now required to count as true.
\item The classification of features as essential or inessential has been
removed. There are now three classes of built-in procedures: primitive,
library, and optional. The optional procedures are {\cf load},
{\cf with-input-from-file}, {\cf with-output-\linebreak[0]to-file},
{\cf transcript-\linebreak[0]on}, {\cf transcript-\linebreak[0]off}, and
{\cf interaction-\linebreak[0]environment},
and {\cf -} and {\cf /} with more than two arguments.
None of these are in the IEEE standard.
\item Programs are allowed to redefine built-in procedures. Doing so
will not change the behavior of other built-in procedures.
\end{itemize}
\item {\em Port} has been added to the list of disjoint types.
\item The macro appendix has been removed. High-level macros are now part
of the main body of the report. The rewrite rules for derived expressions
have been replaced with macro definitions. There are no reserved identifiers.
\item {\cf Syntax-rules} now allows vector patterns.
\item Multiple-value returns, {\cf eval}, and {\cf dynamic-wind} have
been added.
\item The calls that are required to be implemented in a properly tail-recursive
fashion are defined explicitly.
\item `{\cf @}' can be used within identifiers. `{\cf \verb"|"}' is reserved
for possible future extensions.
\end{itemize}
%%R4%%
%\subsection*{Keywords as variable names}
%
%Some implementations allow arbitrary syntactic
%keywords \index{keyword}\index{syntactic keyword}to be used as variable
%names, instead of reserving them, as this report would have
%it.\index{variable} But this creates ambiguities in the interpretation
%of expressions: for example, in the following, it's not clear whether
%the expression {\tt (if 1 2 3)} should be treated as a procedure call or
%as a conditional.
%
%\begin{scheme}
%(define if list)
%(if 1 2 3) \ev 2 {\em{}or} (1 2 3)%
%\end{scheme}
%
%These ambiguities are usually resolved in some consistent way within any
%given implementation, but no particular treatment stands out as being
%clearly superior to any other, so these situations were excluded for the
%purposes of this report.
%%R4%%
%\subsection*{Macros}
%
%Scheme does not have any standard facility for defining new kinds of
%expressions.\index{macros}
%
%\vest The ability to alter the syntax of the language creates
%numerous problems. All current implementations of Scheme have macro
%facilities that solve those problems to one degree or another, but the
%solutions are quite different and it isn't clear at this time which
%solution is best, or indeed whether any of the solutions are truly
%adequate. Rather than standardize, we are encouraging implementations
%to continue to experiment with different solutions.
%
%\vest The main problems with traditional macros are: They must be
%defined to the system before any code using them is loaded; this is a
%common source of obscure bugs. They are usually global; macros can be
%made to follow lexical scope rules \todo{flushed: ``as in Common
%Lisp's {\tt macrolet}''; OK?}, but many people find the resulting scope rules
%confusing. Unless they are written very carefully, macros are
%vulnerable to inadvertent capture of free variables; to get around this,
%for example, macros may have to generate code in which procedure values
%appear as quoted constants. There is a similar problem with syntactic
%keywords if the keywords of special forms are not reserved. If keywords
%are reserved, then either macros introduce new reserved words,
%invalidating old code, or else special forms defined by the programmer
%do not have the same status as special forms defined by the system.
%
%\todo{Refer to Pitman's special forms paper.}
%\todo{Pitman sez: Discuss importance of having a small number of special forms
%so that programs can inspect each other.}
\todo{Move cwcc history back here? --- Andy Cromarty is concerned about
confusion over who the audience is.}
\todo{Cromarty:
23. NOTES, p.35ff.: This material should stay somehow. We need to
make it clear that R$^3$ Scheme is not being touted as Yet Another
Ultimate Solution To The Programming Language Problem, but rather
as a snapshot of a *process* of good design, for which not all
answers have yet been found. We also ought to use the opportunity
for publicity afforded us by SIGPLAN to advertise some of the thorny
unsolved problems that need further research, and encourage
language designers to work on them.}
|