-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsrfi-131.html
177 lines (143 loc) · 8.31 KB
/
srfi-131.html
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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>SRFI 131: ERR5RS Record Syntax (reduced)</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link rel="stylesheet" href="/srfi.css" type="text/css" />
</head>
<body>
<h1>Title</h1>
<p>ERR5RS Record Syntax (reduced)</p>
<h1>Author</h1>
<p>John Cowan, Will Clinger</p>
<h1>Status</h1>
<p>This SRFI is currently in <em>final</em> status. Here is <a href="https://srfi.schemers.org/srfi-process.html">an explanation</a> of each status that a SRFI can hold. To provide input on this SRFI, please send email to <code><a href="mailto:srfi+minus+131+at+srfi+dotschemers+dot+org">srfi-131@<span class="antispam">nospam</span>srfi.schemers.org</a></code>. To subscribe to the list, follow <a href="http://srfi.schemers.org/srfi-list-subscribe.html">these instructions</a>. You can access previous messages via the mailing list <a href="https://srfi-email.schemers.org/srfi-131">archive</a>.</p>
<ul>
<li>Received: 2015-12-07</li>
<li>60-day deadline: 2016-02-05</li>
<li>Draft #1 published: 2015-12-07</li>
<li>Draft #2 published: 2015-12-17</li>
<li>Draft #3 published: 2016-02-06</li>
<li>Finalized: 2016-02-03</li>
</ul>
<h1>Abstract</h1>
<p>This SRFI is a reduced version of the SRFI 99 syntactic layer
that can be implemented with <tt>syntax-rules</tt> without requiring
low-level macros. Like SRFI-99's syntax layer, it is backward
compatible with the <code>define-record-type</code> macro from
<a href="https://srfi.schemers.org/srfi-9/srfi-9.html">SRFI 9</a>
or R7RS-small. It is forward compatible with
<a href="https://srfi.schemers.org/srfi-99/srfi-99.html">SRFI 99</a>.
</p>
<h1>Issues</h1>
<p>No issues at present.</p>
<h1>Rationale</h1>
<p>Implementations of Scheme that provide only <code>syntax-rules</code>
macros cannot currently implement the syntactic layer of SRFI 99. Three
features make a <code>syntax-rules</code> implementation impossible:<p>
<ul><li><p>Specifying <code>#t</code> as the constructor name,
which is equivalent to specifying the type name prefixed by
<tt>make-</tt>.</p></li>
<li>Specifying <code>#t</code> as the predicate name, which is equivalent
to specifying the type name suffixed by <tt>?</tt>.</p></li>
<li><p>Specifying a field spec as either an identifier or a parenthesized
identifier, which are equivalent to specifying an accessor name equivalent
to the type name followed by <code>-</code> followed by the field name,
and (in the latter case) a mutator name equivalent to the type name
followed by <code>-</code> followed by the field name followed by
<code>-set!</code></p></li></ul>
<p>All of these features violate macro hygiene by introducing identifiers
into the code which don't appear in the macro call, which is why
<code>syntax-rules</code> will not suffice to implement them.
However, they are only notational and can be replaced by explicit equivalents in user code.
By eliminating them, as in this SRFI, a pure <code>syntax-rules</code>
implementation such as the sample implementation can provide all the
other features of SRFI 99's syntactic layer.</p>
<h1>Specification</h1>
<h2 id="SyntacticLayer">Syntactic Layer</h2>
<p>
The syntactic layer consists of R7RS <tt>define-record-type</tt> extended with single inheritance and mechanisms for abstract record types.
</p>
<p>
The syntax of a record-type definition is:
</p>
<pre>
<definition>
-> <record type definition>
<record type definition>
-> (define-record-type <type spec>
<constructor spec>
<predicate spec>
<field spec> ...)
<type spec> -> <type name>
-> (<type name> <parent>)
<constructor spec>
-> #f
-> <constructor name>
-> (<constructor name> <field name> ...)
<predicate spec>
-> #f
-> <predicate name>
<field spec> -> (<field name> <accessor name>)
-> (<field name> <accessor name> <mutator name>)
<parent> -> <expression>
<type name> -> <identifier>
<constructor name> -> <identifier>
<predicate name> -> <identifier>
<accessor name> -> <identifier>
<mutator name> -> <identifier>
<field name> -> <identifier>
</pre>
<p>
The semantics of a record type definition is the same as in R7RS-small (or SRFI 9, except that record types are generative).
The record type definition macro-expands into a cluster of definitions that:
</p>
<ul><li>define the <tt><type name></tt> as the record-type descriptor for the new record-type;
</li><li>defines a constructor for instances of the new record-type (unless the constructor spec is <tt>#f</tt>);
</li><li>defines a predicate that recognizes instances of the new record-type and its subtypes (unless the predicate spec is <tt>#f</tt>);
</li><li>defines an accessor for each field name;
</li><li>defines a mutator for each mutable field name.
</li></ul><p>
A record type definition extends R7RS-small with the following additional options:
</p>
<ul><li>If a <tt><parent></tt> expression is specified, then it must evaluate to a record-type descriptor that serves as the parent record-type for the record-type being defined.
</li><li>If <tt>#f</tt> is specified for the constructor or predicate, then no constructor or predicate procedure is defined. (This is useful when the record-type being defined will be used as an abstract base class.)
</li><li>If the constructor name is specified as an identifier, then the constructor's arguments correspond to the fields of the parent (if any) followed by the new fields added by this record-type definition in the specified order.
</li></ul>
<p>When a constructor spec is of the form <code>(<constructor name> <field name> ...)</code>:</p>
<ul>
<li>Each of the field names can be either a field name declared in the same <code>define-record-type</code> form, or any of its ancestors' field names.</li>
<li>If the record definition contains the same field name as one of its ancestors, it shadows the ancestor's field name for the purposes of the constructor. The constructor's argument initializes the child's slot, and the ancestor's slot of the same name is left uninitialized.</li>
<li>It is an error if the same identifier appears more than once in the field names of the constructor spec.</li>
</ul>
<p>These are not explicit in SRFI 99's syntactic layer section, but can be inferred from its description of the procedural layer.</p>
<h1>Implementation</h1>
<p>The sample implementation, a single-file R7RS library, is in the code
repository of this SRFI. It was written by Will Clinger.
It is built on top of the procedural parts of SRFI 99.
</p>
<h1>Copyright</h1>
Copyright (C) John Cowan, Will Clinger (2015). All Rights Reserved.
<p>
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
<p>
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
<p>
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
<hr>
<address>Editor: <a href="mailto:srfi-editors at srfi dot schemers dot org">Arthur A. Gleckler</a></address></body></html>