source: project/wiki/r7rs-tasks @ 36676

Last change on this file since 36676 was 32262, checked in by evhan, 5 years ago

wiki/r7rs-tasks: Remove define-values task

File size: 13.3 KB
Line 
1[[toc:]]
2
3== R7RS Tasks
4
5''(first draft, by felix)''
6
7''comments by John Cowan marked with JC:''
8
9=== General structure
10
11I currently assume that R7RS support will be provided by an egg and a
12minimal set of core enhancements for performance-sensitive
13functionality or features that would require extensive customization
14of existing code.
15
16R7RS library names (lists) can be mapped to module names by
17concatenating the constituents of a library name, separated by "."
18(dot), for example:
19
20  (foo bar baz)   ->   foo.bar.baz
21
22The egg needs to provide a compile-time layer for the expansions of
23library forms and import-resolution in addition to a full set of
24standard libraries. Using the {{r7rs}} egg (for example with
25{{require-extension}}) will automatically load and import all r7rs
26standard libraries into the toplevel environment. On the other hand
27R7RS modules defined with "define-library" will have initially only
28{{import}}, which will be needed to expand imports (strictly speaking,
29the initial module environment should be empty, but this is how the
30module system currently works).
31
32There is probably no way around including the full numeric tower -
33providing a mode with a restricted set of numeric types would
34complicate the R7RS support quite considerably. The
35[[/eggref/4/numbers|numbers]] egg is likely to need some enhancements
36({{equal[=]?}} with handling of circular data, see below).
37* JC: I don't understand why things would be complicated with CHICKEN's default fixnum/flonum support.  There is no {{equal=?}} in R7RS, and {{equal?}} should not be affected.
38* JC: What about making full Unicode support the default?  R7RS does not require it, but it might be better so.
39
40Full type-declarations for all exports should be provided, both for
41error checking and performance. It would also be worthwhile to
42identify small inlinable R7RS primitives and generate ".inline" files
43for all standard libraries, if candidates for global inlining exist.
44
45Some R7RS primitives are partially or completely provided by SRFI-1
46and SRFI-13, but I think it would be better to implement them
47directly, to make them as efficient as possible. The existing code is
48in many cases not tuned to the implementation and makes assumptions
49about Scheme code performance that may have been valid 30 years ago
50but aren't anymore nowadays.
51
52=== Todo
53
54Outstanding tasks:
55
56* {{\x}} escapes in {{|...|}}
57* {{#\x...;}} character syntax
58* {{export}} renaming
59* {{eqv?}} corner cases
60* {{equal?}} must not diverge
61* {{with-exception-handler}} thread safety
62
63Nice to haves:
64
65* {{(srfi 1)}} and {{(srfi 13)}} reexport optimizations
66* {{.inline}} files
67* {{.types}} specializations
68* {{.sld}} file support
69* {{#!fold-case}} support without {{(import (scheme read))}}
70
71The egg also needs a more comprehensive test suite.
72
73=== Classification of changes
74
75; (+) : Trivial or straightforward changes
76; (*) : Changes that are difficult or work-intensive
77; (X) : Changes that break backwards-compatibility
78; (?) : Needs to be clarified
79
80=== Changes that are likely to be implemented in the core system
81
82==== 2.1. Identifiers
83
84* {{|...|}} needs support for {{\x...;}} escape syntax, which is not fully compatible to the existing {{\xXX}} format. A backwards-compatible change should be possible but will have ambiguous cases like {{|\x12;|}}. (X)
85
86* {{#!fold-case}}, {{#!no-fold-case}}. Do these apply over files? (for example when used inside included files) (+)
87** JC: They apply only to the file in which they appear, not to any included or including file, because they work at a lower level (that is, {{read}} implements them).
88** PB: This is a problem, because our "case-sensitive" parameter is global, not bound to the port.  Here's a test case that I came up with for this (it can go into tests/r7rs-tests.scm):
89** EH: Pushed to egg under {{(scheme read)}}.
90
91<enscript highlight="scheme">
92(SECTION 2 1)
93
94(test '(mooh qux blah foo BAR)
95      (append
96       (with-input-from-string
97           "#!fold-case mooh QUX blah #!no-fold-case foo BAR" read-file)))
98
99;; #!(no-)fold-case "affect the reading of subsequent data *from the same port*"
100(test '(foo bar downcased UPCASED)
101      (append
102       (with-input-from-string
103           "#!fold-case foo BAR" read-file)
104       (with-input-from-string
105           "downcased UPCASED" read-file)))
106</enscript>
107
108From what I can see, this means a flag needs to be added to the
109*port*, so that repeated invocations of READ can communicate this to
110eachother.
111
112==== 4.2.2. Binding constructs
113
114* {{letrec*}}. Change all internal uses of {{letrec}} to {{letrec*}} and add a correct implementation of {{letrec}}. This will produce a bootstrapping problem (the compilation of syntactic forms that expand into uses of {{letrec*}} will require a compiler with support for {{letrec*}}), which can be solved but needs to be done with care. (+)
115** JC: In R7RS (though not in R6RS), {{letrec*}} ''is'' a valid implementation of {{letrec}}, which retroactively approves CHICKEN's strategy.  So nothing needs to be done except to add {{letrec*}} as a synonym for {{letrec}}.
116** EH: Pushed to core.
117
118==== 4.2.5. Delayed evaluation
119
120* {{delay-force}}. I don't know how this works, it may be useful to have this in the core-system, though. (?)
121** JC: See SRFI 45.  The R7RS {{delay}}, {{force}}, {{delay-force}}, and {{make-promise}} in R7RS correspond exactly to {{delay}}, {{force}}, {{lazy}}, and {{eager}} in that SRFI.
122** EH: Pushed to core.
123
124* {{make-promise}}: expose wrapper for {{##sys#make-promise}}. (+)
125** EH: Pushed to core.
126
127==== 4.3.2. Pattern language (syntax-rules)
128
129* "Underscores also match arbitrary input elements but are not pattern variables ...": is this currently the case? (?)
130** PB: Not currently the case, underscore is treated like any other identifier. Patch posted to -hackers to change this.
131** EH: Pushed to egg.
132
133* {{(<ellipsis> <template>)}}. This is currently not available, IIRC. (? *)
134** PB: Indeed not available yet. Patch posted for that as well.
135** EH: Pushed to egg.
136
137==== 6.3. Booleans
138
139* Add {{#true}}, {{#false}}. (+)
140** EH: Pushed to egg.
141
142(BTW, I find these depressing. Is it really so difficult for newcomers to learn {{#t}} and {{#f}}?)
143
144JC: The theory is that {{#t}} and {{#f}} are too easily mistaken for each other by a human reader.  I don't find it so, but apparently others do.
145
146ZB: I would also suggest {{#one}} and {{#ell}} to prevent further ambiguity.  Repeat recursively for {{#ell}} as needed.
147
148AS: ZB: Actually, programmers I know fairly universally avoid using single lowercase "l" as a variable name for precisely that reason.
149
150==== 6.6. Characters
151
152* Additional named chars ({{#\alarm}}, ...) (+)
153** PB: Implemented and pushed to core.
154
155* Can someone explain to me what {{char-foldcase}} does? (?)
156** JC: On an ASCII platform, {{char-foldcase}} and {{string-foldcase}} are the same as {{char-downcase}} and {{string-downcase}} respectively.  For Unicode, {{char-foldcase}} implements [[http://www.unicode.org/Public/UNIDATA/CaseFolding.txt|Unicode case folding]], specifically the table entries marked with "C" and "S", but not those marked with "F" or "T".  {{string-foldcase}}, on the other hand, implements the table entries marked with "C" and "F", but not those marked with "S" or "T".
157** EH: Pushed to egg (ASCII-only).
158
159* Extend {{char=?}}, {{char<?}} et al. to accept arbitrarily many arguments. (+)
160** EH: Pushed to egg.
161
162==== 6.7. Strings
163
164* {{\a}} escape syntax. (+)
165** PB: Implemented and pushed to core.
166
167* {{\<Intraline whitespace>}}. (+)
168** PB: Implemented and pushed to core.
169
170* {{\x...;}} syntax. The same issues as in {{|...|}} identifier names. (X)
171
172* Extend {{string=?}}, {{string<?}} et al. to accept arbitrarily many arguments. (+)
173** EH: Pushed to egg.
174
175
176==== 6.8. Vectors
177
178* Self-evaluating vectors.
179** PB: Implemented and pushed to core.
180
181(My heart bleeds)
182
183
184==== 6.9. Bytevectors
185
186* Self-evaluating u8vectors.
187** PB: Implemented and pushed to core.
188
189* Note for future hackers:  it's right to implement bytevectors as u8vectors, not as blobs, for better compatibility with pre-R7RS CHICKEN code.  You just can't do enough with blobs.
190
191==== 6.13.3. Output
192
193* {{write}}. Support for labels and circle-detection. This probably needs to be implemented in the core reader or will require ugly hooks that we probably want to avoid. (*)
194** EH: Pushed to egg.
195
196==== Appendix B
197
198* Without a canonical list of features and their exact meaning this is mostly useless. (?)
199** JC: The ones that CHICKEN should provide are {{r7rs}}, {{ieee-float}}, and either {{posix}} or {{windows}} as the case may be.  If the full numeric tower is provided, add {{exact-closed}}, {{exact-complex}}, and {{ratios}}.  If Unicode is provided, add {{full-unicode}}.  This should be integrated with the CHICKEN native {{(features)}} list.
200
201=== Implementations in the r7rs egg that override core functionality
202
203==== 4.1.7. Inclusion
204
205* Multi-argument {{include}}, {{include-ci}} (+)
206** EH: Pushed to egg.
207
208==== 4.2.1. Conditionals
209
210* {{=>}} in {{case}} constructs (+)
211** PB: Pushed to core.
212
213* {{cond-expand}} needs support for {{library}}. This may need to scan available modules (i.e. query the repository for installed extensions) (*)
214** JC: Just so.
215** EH: Pushed to egg.
216
217==== 4.2.6 Dynamic bindings
218
219* There is no problem with using CHICKEN parameters directly as R7RS parameters.
220
221==== 5.2. Import declarations
222
223* {{import}}. A library name may not begin with a modifier-keyword like {{only}}, right? (? *)
224** JC: Right.  The important thing here is that in an R7RS library or program, {{import}} is CHICKEN's {{use}}.
225** EH: Pushed to egg.
226
227==== 5.3.3. Multiple-value definitions
228
229By having {{letrec*}} semantics for internal definitions, this implementation of {{define-values}}
230by Alex Shinn is sufficient for handling toplevel and local multiple-value definitions (special
231handling in lambda-body expansion is not necessary anymore):
232
233<enscript highlight=scheme>
234(define-syntax define-values
235  (syntax-rules ()
236    ((_ (var  ...) expr)
237     (define-values-sub () (var ...) () expr))
238    ((_ . else)
239     (syntax-error "malformed define-values" (define-values . else)))
240    ))
241
242(define-syntax define-values-sub
243  (syntax-rules ()
244    ((_ (tmp ...) (last-var) (var ...) expr)
245     ;; place the last var at the start of the list
246     (define-values-sub (tmp1 tmp ...) () (last-var var ...) expr))
247    ((_ (last-tmp tmp ...) () (last-var var ...) expr)
248     (begin (define var #f) ... ;(undefined)
249            (define last-var
250              (receive (tmp ... last-tmp) expr
251                (set! var tmp) ...
252                last-tmp))))
253    ((_ (tmp ...) (v v2 ...) (var ...) expr)
254     (define-values-sub (tmp ... tmp1) (v2 ...) (var ... v) expr))
255    ))
256</enscript>
257
258==== 5.5. Record-type definitions
259
260* {{define-record-type}}. Is generative (*)
261** EH: Pushed to egg.
262
263==== 5.6.1. Library syntax
264
265* The {{export}} declaration will require renaming, which is currently not available in the module system. Requires a bit of work. (*)
266
267==== 5.7 The REPL
268
269* Doing {{(use r7rs)}} at the REPL should import {{(scheme base)}}, but it doesn't.
270
271==== 6.1. Equivalence predicates
272
273* {{eqv?}} may have some corner cases for funny IEEE values (nan, etc.). (?)
274
275* {{equal?}} must handle circular data. Change this in core? Probably, since this needs to be fast. Applies to {{equal=?}} as well. (? *)
276
277==== 6.4. Pairs and lists
278
279* {{make-list}}. See SRFI-1. (+)
280** EH: Pushed to egg.
281
282* 3-argument {{member}} and {{assoc}}. See SRFI-1. (+)
283** EH: Pushed to egg.
284
285==== 6.7. Strings
286
287* {{string->list}} with start/end arguments. (+)
288** EH: Pushed to egg.
289
290* {{string-copy}}, {{string-copy!}} and {{string-fill!}} with start/end arguments. See SRFI-13. Provide specializations for case when limits are not given. (+)
291** EH: Pushed to egg (w/o specializations ATM).
292
293==== 6.8. Vectors
294
295* {{vector->list}}, {{list->vector}} and {{string->vector}} with start/end arguments. Provide specializations. (+)
296** EH: Pushed to egg (w/o specializations ATM).
297
298* {{vector-copy!}} and {{vector-fill!}} with start/end arguments. (+)
299** EH: Pushed to egg.
300
301==== 6.10. Control features
302
303* {{string-map}} and {{string-for-each}} are not compatible with SRFI-13 version. (+)
304** EH: Pushed to egg.
305
306==== 6.11. Exceptions
307
308* {{with-exception-handler}}. I think this is not compatible to the current version. (? *)
309
310* Clarify exact semantics of {{raise}}. (? *)
311
312* Implementing {{guard}} correctly will need some thought, due to the wild jumping between dynamic environments. (*)
313
314==== 6.12. Environments and evaluation
315
316* {{environment}}. Not sure how to do this. (? *)
317** JC: The point of these environments is that they can be passed to {{eval}}; they are parallel to the environments returned by {{scheme-report-environment}}, {{null-environment}}, and {{interaction-environment}}.
318** EH: Pushed to egg.
319
320* Clarify immutability of environments. Can we just ignore this requirement? (?)
321** JC: In practice, yes.
322** EH: Pushed to egg (by way of doing nothing at all).
323
324==== 6.13.1. Ports
325
326* {{get-output-string}}. Does it clear the buffer, as it does in SRFI-whatever? (?)
327** No, it doesn't, as in SRFI 6.
328** EH: Pushed to egg (by simply reexporting {{get-output-string}}).
329
330==== 6.13.3. Output
331
332* {{write-string}} with start/end arguments. (+)
333** EH: Pushed to egg.
334
335==== 6.14. System interface
336
337* 2-argument {{load}}. (?)
338** JC: The second argument is passed along to {{eval}}.
339** EH: Pushed to egg.
340
341* {{exit}} with boolean arguments. (+)
342** EH: Pushed to egg.
343
344* What the heck should be used as {{jiffy}}? On which platforms? (?)
345** JC: Seconds or milliseconds as you see fit.
346** EH: Pushed to egg (with milliseconds as jiffies).
Note: See TracBrowser for help on using the repository browser.