This repository has been archived by the owner on Oct 5, 2024. It is now read-only.
forked from scheme-requests-for-implementation/srfi-1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
srfi-1.html
3716 lines (3566 loc) · 140 KB
/
srfi-1.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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<!-- Is there a portable way to write an em-dash?
Can I have bangs, plusses, or slashes in #tags? Spaces?
Yes: plus, bang, star No: space Yes: slash, question, ampersand
You can't put sharp in a path, so anything goes, really.
Nonetheless, some of these confuse Netscape, so I'll avoid them.
-->
<!--========================================================================-->
<html lang="en-US">
<head>
<!--
SPDX-FileCopyrightText: 1998 - 1999 Olin Shivers
SPDX-License-Identifier: MIT
-->
<meta charset="utf-8" />
<meta content="Scheme, programming language, list processing, SRFI" name="keywords" />
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link href="https://srfi.schemers.org/srfi.css" rel="stylesheet" type="text/css" />
<link href="/favicon.png" rel="icon" sizes="192x192" type="image/png" />
<title>SRFI 1: List Library</title>
<!-- Should have a media=all to get, for example, printing to work.
== But my Netscape will completely ignore the tag if I do that.
-->
<style type="text/css">
/*<![CDATA[*/
/* A little general layout hackery for headers & the title. */
body { margin-left: +7%;
font-family: "Helvetica", sans-serif;
}
/* Netscape workaround: */
td, th { font-family: "Helvetica", sans-serif; }
code, pre { font-family: "courier new", "courier"; }
h1 { margin-left: -5%; }
h1, h2 { clear: both; }
h1, h2, h3, h4, h5, h6 { color: blue }
div.title-text { font-size: large; font-weight: bold; }
div.indent { margin-left: 2em; } /* General indentation */
pre.code-example { margin-left: 2em; } /* Indent code examples. */
/* This stuff is for definition lists of defined procedures.
** A proc-def2 is used when you want a stack of procs to go
** with one <dd> ... </dd> body. In this case, make the first
** proc a proc-def1, following ones proc-defi's, and the last one
** a proc-defn.
**
** Unfortunately, Netscape has huge bugs with respect to style
** sheets and dl list rendering. We have to set truly random
** values here to get the rendering to come out. The proper values
** are in the following style sheet, for Internet Explorer.
** In the following settings, the *comments* say what the
** setting *really* causes Netscape to do.
**
** Ugh. Professional coders sacrifice their self-respect,
** that others may live.
*/
/* m-t ignored; m-b sets top margin space. */
dt.proc-def1 { margin-top: 0ex; margin-bottom: 3ex; }
dt.proc-defi { margin-top: 0ex; margin-bottom: 0ex; }
dt.proc-defn { margin-top: 0ex; margin-bottom: 0ex; }
/* m-t works weird depending on whether or not the last line
** of the previous entry was a pre. Set to zero.
*/
dt.proc-def { margin-top: 0ex; margin-bottom: 3ex; }
/* m-b sets space between dd & dt; m-t ignored. */
dd.proc-def { margin-bottom: 0.5ex; margin-top: 0ex; }
/* Boldface the name of a procedure when it's being defined. */
code.proc-def { font-weight: bold; font-size: 110%}
/* For the index of procedures.
** Same hackery as for dt.proc-def, above.
*/
/* m-b sets space between dd & dt; m-t ignored. */
dd.proc-index { margin-bottom: 0ex; margin-top: 0ex; }
/* What the fuck? */
pre.proc-index { margin-top: -2ex; }
/* Pull the table of contents back flush with the margin.
** Both NS & IE screw this up in different ways.
*/
#toc-table { margin-top: -2ex; margin-left: -5%; }
/* R5RS proc names are in italic; extended R5RS names
** in italic boldface.
*/
span.r5rs-proc { font-weight: bold; }
span.r5rs-procx { font-style: italic; font-weight: bold; }
/* Spread out bibliographic lists. */
/* More Netscape-specific lossage; see the following stylesheet
** for the proper values (used by IE).
*/
dt.biblio { margin-bottom: 1ex; }
/* Links to draft copies (e.g., not at the official SRFI site)
** are colored in red, so people will use them during the
** development process and kill them when the document's done.
*/
a.draft { color: red; }
/*]]>*/
</style>
<style media="all" type="text/css">
/*<![CDATA[*/
/* Nastiness: Here, I'm using a bug to work around a bug.
** Netscape rendering bugs mean you need bogus <dt> and <dd>
** margin settings -- settings which screw up IE's proper rendering.
** Fortunately, Netscape has *another* bug: it will ignore this
** media=all style sheet. So I am placing the (proper) IE values
** here. Perhaps, one day, when these rendering bugs are fixed,
** this gross hackery can be removed.
*/
dt.proc-def1 { margin-top: 3ex; margin-bottom: 0ex; }
dt.proc-defi { margin-top: 0ex; margin-bottom: 0ex; }
dt.proc-defn { margin-top: 0ex; margin-bottom: 0.5ex; }
dt.proc-def { margin-top: 3ex; margin-bottom: 0.5ex; }
pre { margin-top: 1ex; }
dd.proc-def { margin-bottom: 2ex; margin-top: 0.5ex; }
/* For the index of procedures.
** Same hackery as for dt.proc-def, above.
*/
dd.proc-index { margin-top: 0ex; }
pre.proc-index { margin-top: 0ex; }
/* Spread out bibliographic lists. */
dt.biblio { margin-top: 3ex; margin-bottom: 0ex; }
dd.biblio { margin-bottom: 1ex; }
/*]]>*/
</style>
</head>
<body>
<!--========================================================================-->
<h1><a href="https://srfi.schemers.org/"><img alt="SRFI surfboard logo" class="srfi-logo" src="https://srfi.schemers.org/srfi-logo.svg" /></a>1: List Library</h1>
<p>by Olin Shivers</p>
<!--========================================================================-->
<h2 id="status">Status</h2>
<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+1%20%20+at+srfi+dotschemers+dot+org">srfi-1 @<span class="antispam">nospam</span>srfi.schemers.org</a></code>. To subscribe to the list, follow <a href="https://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-1">archive</a>.</p>
<ul>
<li>Received: 1998-11-08</li>
<li>Draft: 1998-12-22--1999-03-09</li>
<li>Revised: several times</li>
<li>Final: 1999-10-09</li>
<li>Revised to fix errata:
<ul>
<li>2016-08-27 (Clarify Booleans.)</li>
<li>2018-10-08 (Remove extra parenthesis.)</li>
<li>2019-10-25 (Fix broken links.)</li>
<li>2020-06-02 (Add <a href="#lset%3D-element-equality-order">note</a>
about order of arguments to <code>lset=</code>.)</li>
<li>2022-10-22 (Fixed <a href="#reduce-right">definition of <code>reduce-right</code></a>. See <a href="https://srfi-email.schemers.org/srfi-1/msg/18561246/">discussion in archive</a>.)</li>
<li>2022-11-21 (Add missing ellipsis in signature of <a href="#count"><code>count</code></a>.)</li>
<li>2023-04-27 (Fix return type of <a href="#circular-list"><code>circular-list</code></a>.)</li>
</ul>
</li>
</ul>
<!--========================================================================-->
<h2>Table of contents</h2>
<!-- A bug in netscape (?) keeps the first link in this UL from being active.
==== So the Abstract link be dead. 99/8/22 -Olin
-->
<ul id="toc-table">
<li><a href="#Abstract">Abstract</a></li>
<li><a href="#Rationale">Rationale</a></li>
<li><a href="#ProcedureIndex">Procedure index</a></li>
<li>
<a href="#GeneralDiscussion">General discussion</a>
<ul>
<li><a href="#LinearUpdateProcedures">"Linear update" procedures</a></li>
<li><a href="#ImproperLists">Improper lists</a></li>
<li><a href="#Errors">Errors</a></li>
<li><a href="#NotIncludedInThisLibrary">Not included in this library</a></li>
</ul>
</li>
<li>
<a href="#TheProcedures">The procedures</a>
<ul>
<li><a href="#Constructors">Constructors</a></li>
<li><a href="#Predicates">Predicates</a></li>
<li><a href="#Selectors">Selectors</a></li>
<li><a href="#Miscellaneous">Miscellaneous: length, append, reverse, zip & count</a></li>
<li><a href="#FoldUnfoldMap">Fold, unfold, and map</a></li>
<li><a href="#FilteringPartitioning">Filtering & partitioning</a></li>
<li><a href="#Searching">Searching</a></li><li><a href="#Deletion">Deletion</a></li>
<li><a href="#AssociationLists">Association lists</a></li>
<li><a href="#SetOperationsOnLists">Set operations on lists</a></li>
<li><a href="#PrimitiveSideEffects">Primitive side-effects</a></li>
</ul>
</li>
<li><a href="#Acknowledgements">Acknowledgements</a></li>
<li><a href="#ReferencesLinks">References & links</a></li>
<li><a href="#Copyright">Copyright</a></li>
</ul>
<!--========================================================================-->
<h2 id="Abstract">Abstract</h2>
<p>
<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> Scheme has an impoverished set of list-processing utilities, which is a
problem for authors of portable code. This <abbr title="Scheme Request for Implementation">SRFI</abbr> proposes a coherent and
comprehensive set of list-processing procedures; it is accompanied by a
reference implementation of the spec. The reference implementation is
</p>
<ul>
<li>portable</li>
<li>efficient</li>
<li>completely open, public-domain source</li>
</ul>
<!--========================================================================-->
<h2 id="Rationale">Rationale</h2>
<p>
The set of basic list and pair operations provided by R4RS/<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> Scheme is far
from satisfactory. Because this set is so small and basic, most
implementations provide additional utilities, such as a list-filtering
function, or a "left fold" operator, and so forth. But, of course, this
introduces incompatibilities -- different Scheme implementations provide
different sets of procedures.
</p>
<p>
I have designed a full-featured library of procedures for list processing.
While putting this library together, I checked as many Schemes as I could get
my hands on. (I have a fair amount of experience with several of these
already.) I missed Chez -- no on-line manual that I can find -- but I hit most
of the other big, full-featured Schemes. The complete list of list-processing
systems I checked is:
</p>
<div class="indent">
<abbr title="Revised^4 Report on Scheme">R4RS</abbr>/<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> Scheme, MIT Scheme, Gambit, RScheme, MzScheme, slib,
<a href="#CommonLisp">Common Lisp</a>, Bigloo, guile, T, APL and the SML standard basis
</div>
<p>
As a result, the library I am proposing is fairly rich.
</p>
<p>
Following this initial design phase, this library went through several
months of discussion on the SRFI mailing lists, and was altered in light
of the ideas and suggestions put forth during this discussion.
</p>
<p>
In parallel with designing this API, I have also written a reference
implementation. I have placed this source on the Net with an unencumbered,
"open" copyright. A few notes about the reference implementation:
</p>
<ul>
<li>Although I got procedure names and specs from many Schemes, I wrote this
code myself. Thus, there are <em>no</em> entanglements.
Any Scheme implementor
can pick this library up with no worries about copyright problems -- both
commercial and non-commercial systems.
</li><li>The code is written for portability and should be trivial to port to
any Scheme. It has only four deviations from <abbr title="Revised^4 Report on Scheme">R4RS</abbr>, clearly discussed
in the comments: <ul>
<li>Use of an <code>error</code> procedure;
</li><li>Use of the <abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> <code>values</code> and a simple <code>receive</code> macro for producing
and consuming multiple return values;
</li><li>Use of simple <code>:optional</code> and <code>let-optionals</code> macros for optional
argument parsing and defaulting;
</li><li>Use of a simple <code>check-arg</code> procedure for argument checking.
</li></ul>
</li><li>It is written for clarity and well-commented. The current source is
768 lines of source code and 826 lines of comments and white space.
</li><li><p>
It is written for efficiency. Fast paths are provided for common
cases. Side-effecting procedures such as <code>filter!</code> avoid unnecessary,
redundant <code>set-cdr!</code>s which would thrash a generational GC's write barrier
and the store buffers of fast processors. Functions reuse longest common
tails from input parameters to construct their results where
possible. Constant-space iterations are used in preference to recursions;
local recursions are used in preference to consing temporary intermediate
data structures.
</p>
<p>
This is not to say that the implementation can't be tuned up for
a specific Scheme implementation. There are notes in comments addressing
ways implementors can tune the reference implementation for performance.
</p></li></ul>
<p>
In short, I've written the reference implementation to make it as painless
as possible for an implementor -- or a regular programmer -- to adopt this
library and get good results with it.
</p>
<!--========================================================================-->
<h2 id="ProcedureIndex">Procedure Index</h2>
<p>
Here is a short list of the procedures provided by the list-lib package.
<a href="#R5RS">R5RS</a> procedures are shown in
<span class="r5rs-proc">bold</span>;
extended <a href="#R5RS">R5RS</a>
procedures, in <span class="r5rs-procx">bold italic</span>.
</p>
<div class="indent">
<dl>
<dt class="proc-index"> Constructors
</dt><dd class="proc-index">
<pre class="proc-index">
<span class="r5rs-proc"><a href="#cons">cons</a> <a href="#list">list</a></span>
<a href="#xcons">xcons</a> <a href="#cons*">cons*</a> <a href="#make-list">make-list</a> <a href="#list-tabulate">list-tabulate</a>
<a href="#list-copy">list-copy</a> <a href="#circular-list">circular-list</a> <a href="#iota">iota</a>
</pre>
</dd><dt class="proc-index"> Predicates
</dt><dd class="proc-index">
<pre class="proc-index">
<span class="r5rs-proc"><a href="#pair-p">pair?</a> <a href="#null-p">null?</a></span>
<a href="#proper-list-p">proper-list?</a> <a href="#circular-list-p">circular-list?</a> <a href="#dotted-list-p">dotted-list?</a>
<a href="#not-pair-p">not-pair?</a> <a href="#null-list-p">null-list?</a>
<a href="#list%3D">list=</a>
</pre>
</dd><dt class="proc-index"> Selectors
</dt><dd class="proc-index">
<pre class="proc-index">
<span class="r5rs-proc"><a href="#car">car</a> <a href="#cdr">cdr</a> ... <a href="#cddadr">cddadr</a> <a href="#cddddr">cddddr</a> <a href="#list-ref">list-ref</a></span>
<a href="#first">first</a> <a href="#second">second</a> <a href="#third">third</a> <a href="#fourth">fourth</a> <a href="#fifth">fifth</a> <a href="#sixth">sixth</a> <a href="#seventh">seventh</a> <a href="#eighth">eighth</a> <a href="#ninth">ninth</a> <a href="#tenth">tenth</a>
<a href="#car%2Bcdr">car+cdr</a>
<a href="#take">take</a> <a href="#drop">drop</a>
<a href="#take-right">take-right</a> <a href="#drop-right">drop-right</a>
<a href="#take!">take!</a> <a href="#drop-right!">drop-right!</a>
<a href="#split-at">split-at</a> <a href="#split-at!">split-at!</a>
<a href="#last">last</a> <a href="#last-pair">last-pair</a>
</pre>
</dd><dt class="proc-index"> Miscellaneous: length, append, concatenate, reverse, zip & count
</dt><dd class="proc-index">
<pre class="proc-index">
<span class="r5rs-proc"><a href="#length">length</a></span> <a href="#length%2B">length+</a>
<span class="r5rs-proc"><a href="#append">append</a></span> <a href="#concatenate">concatenate</a> <span class="r5rs-proc"><a href="#reverse">reverse</a></span>
<a href="#append!">append!</a> <a href="#concatenate!">concatenate!</a> <a href="#reverse!">reverse!</a>
<a href="#append-reverse">append-reverse</a> <a href="#append-reverse!">append-reverse!</a>
<a href="#zip">zip</a> <a href="#unzip1">unzip1</a> <a href="#unzip2">unzip2</a> <a href="#unzip3">unzip3</a> <a href="#unzip4">unzip4</a> <a href="#unzip5">unzip5</a>
<a href="#count">count</a>
</pre>
</dd><dt class="proc-index"> Fold, unfold & map
</dt><dd class="proc-index">
<pre class="proc-index">
<span class="r5rs-procx"><a href="#map">map</a> <a href="#for-each">for-each</a></span>
<a href="#fold">fold</a> <a href="#unfold">unfold</a> <a href="#pair-fold">pair-fold</a> <a href="#reduce">reduce</a>
<a href="#fold-right">fold-right</a> <a href="#unfold-right">unfold-right</a> <a href="#pair-fold-right">pair-fold-right</a> <a href="#reduce-right">reduce-right</a>
<a href="#append-map">append-map</a> <a href="#append-map!">append-map!</a>
<a href="#map!">map!</a> <a href="#pair-for-each">pair-for-each</a> <a href="#filter-map">filter-map</a> <a href="#map-in-order">map-in-order</a>
</pre>
</dd><dt class="proc-index"> Filtering & partitioning
</dt><dd class="proc-index">
<pre class="proc-index">
<a href="#filter">filter</a> <a href="#partition">partition</a> <a href="#remove">remove</a>
<a href="#filter!">filter!</a> <a href="#partition!">partition!</a> <a href="#remove!">remove!</a>
</pre>
</dd><dt class="proc-index"> Searching
</dt><dd class="proc-index">
<pre class="proc-index">
<span class="r5rs-procx"><a href="#member">member</a></span> <span class="r5rs-proc"><a href="#memq">memq</a> <a href="#memv">memv</a></span>
<a href="#find">find</a> <a href="#find-tail">find-tail</a>
<a href="#any">any</a> <a href="#every">every</a>
<a href="#list-index">list-index</a>
<a href="#take-while">take-while</a> <a href="#drop-while">drop-while</a> <a href="#take-while!">take-while!</a>
<a href="#span">span</a> <a href="#break">break</a> <a href="#span!">span!</a> <a href="#break!">break!</a>
</pre>
</dd><dt class="proc-index"> Deleting
</dt><dd class="proc-index">
<pre class="proc-index">
<a href="#delete">delete</a> <a href="#delete-duplicates">delete-duplicates</a>
<a href="#delete!">delete!</a> <a href="#delete-duplicates!">delete-duplicates!</a>
</pre>
</dd><dt class="proc-index"> Association lists
</dt><dd class="proc-index">
<pre class="proc-index">
<span class="r5rs-procx"><a href="#assoc">assoc</a></span> <span class="r5rs-proc"><a href="#assq">assq</a> <a href="#assv">assv</a></span>
<a href="#alist-cons">alist-cons</a> <a href="#alist-copy">alist-copy</a>
<a href="#alist-delete">alist-delete</a> <a href="#alist-delete!">alist-delete!</a>
</pre>
</dd><dt class="proc-index"> Set operations on lists
</dt><dd class="proc-index">
<pre class="proc-index">
<a href="#lset%3C%3D">lset<=</a> <a href="#lset%3D">lset=</a> <a href="#lset-adjoin">lset-adjoin</a>
<a href="#lset-union">lset-union</a> <a href="#lset-union!">lset-union!</a>
<a href="#lset-intersection">lset-intersection</a> <a href="#lset-intersection!">lset-intersection!</a>
<a href="#lset-difference">lset-difference</a> <a href="#lset-difference!">lset-difference!</a>
<a href="#lset-xor">lset-xor</a> <a href="#lset-xor!">lset-xor!</a>
<a href="#lset-diff%2Bintersection">lset-diff+intersection</a> <a href="#lset-diff%2Bintersection!">lset-diff+intersection!</a>
</pre>
</dd><dt class="proc-index"> Primitive side-effects
</dt><dd class="proc-index">
<pre class="proc-index">
<span class="r5rs-proc"><a href="#set-car!">set-car!</a> <a href="#set-cdr!">set-cdr!</a></span>
</pre>
</dd></dl>
</div>
<p>
Four <abbr title="Revised^4 Report on Scheme">R4RS</abbr>/<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> list-processing procedures are extended by this library in
backwards-compatible ways:
</p>
<div class="indent">
<table cellspacing="0">
<tr valign="baseline"><td><code>map for-each</code>
</td><td>(Extended to take lists of unequal length)
</td></tr><tr valign="baseline"><td><code>member assoc</code>
</td><td>(Extended to take an optional comparison procedure.)
</td></tr></table>
</div>
<p>
The following <abbr title="Revised^4 Report on Scheme">R4RS</abbr>/<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> list- and pair-processing procedures are also part of
list-lib's exports, as defined by the <abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr>:
</p>
<div class="indent">
<pre>
cons pair? null?
car cdr ... cdddar cddddr
set-car! set-cdr!
list append reverse
length list-ref
memq memv assq assv
</pre>
</div>
<p>
The remaining two <abbr title="Revised^4 Report on Scheme">R4RS</abbr>/<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> list-processing
procedures are <em>not</em> part of
this library:
</p>
<div class="indent">
<table cellspacing="0">
<tr><td><code>list-tail</code>
</td><td>(renamed <code>drop</code>)
</td></tr><tr valign="baseline"><td><code>list?</code>
</td><td>(see <code>proper-list?</code>,
<code>circular-list?</code> and
<code>dotted-list?</code>)
</td></tr></table>
</div>
<!--========================================================================-->
<h2 id="GeneralDiscussion">General discussion</h2>
<p>
A set of general criteria guided the design of this library.
</p>
<p>
I don't require "destructive" (what I call "linear update") procedures to
alter and recycle cons cells from the argument lists. They are allowed to, but
not required to. (And the reference implementations I have written <em>do</em>
recycle the argument lists.)
</p>
<p>
List-filtering procedures such as <code>filter</code> or <code>delete</code> do not disorder
lists. Elements appear in the answer list in the same order as they appear in
the argument list. This constrains implementation, but seems like a desirable
feature, since in many uses of lists, order matters. (In particular,
disordering an alist is definitely a bad idea.)
</p>
<p>
Contrariwise, although the reference implementations of the list-filtering
procedures share longest common tails between argument and answer lists,
it not is part of the spec.
</p>
<p>
Because lists are an inherently sequential data structure (unlike, say,
vectors), list-inspection functions such as <code>find</code>, <code>find-tail</code>, <code>for-each</code>, <code>any</code>
and <code>every</code> commit to a left-to-right traversal order of their argument list.
</p>
<p>
However, constructor functions, such as <code><code>list-tabulate</code></code> and the mapping
procedures (<code>append-map</code>, <code>append-map!</code>, <code>map!</code>, <code>pair-for-each</code>, <code>filter-map</code>,
<code>map-in-order</code>), do <em>not</em> specify the dynamic order in which their procedural
argument is applied to its various values.
</p>
<p>
Predicates return useful true values wherever possible. Thus <code>any</code> must return
the true value produced by its predicate, and <code>every</code> returns the final true
value produced by applying its predicate argument to the last element of its
argument list.
</p>
<p>
Functionality is provided both in pure and linear-update (potentially
destructive) forms wherever this makes sense.
</p>
<p>
No special status accorded Scheme's built-in equality functions.
Any functionality provided in terms of <code>eq?</code>, <code>eqv?</code>, <code>equal?</code> is also
available using a client-provided equality function.
</p>
<p>
Proper design counts for more than backwards compatibility, but I have tried,
<em>ceteris paribus</em>,
to be as backwards-compatible as possible with existing
list-processing libraries, in order to facilitate porting old code to run as a
client of the procedures in this library. Name choices and semantics are, for
the most part, in agreement with existing practice in many current Scheme
systems. I have indicated some incompatibilities in the following text.
</p>
<p>
These procedures are <em>not</em> "sequence generic" -- <em>i.e.</em>, procedures that
operate on either vectors and lists. They are list-specific. I prefer to
keep the library simple and focussed.
</p>
<p>
I have named these procedures without a qualifying initial "list-" lexeme,
which is in keeping with the existing set of list-processing utilities in
Scheme.
I follow the general Scheme convention (vector-length, string-ref) of
placing the type-name before the action when naming procedures -- so
we have <code>list-copy</code> and <code>pair-for-each</code> rather than the perhaps
more fluid, but less consistent, <code>copy-list</code> or <code>for-each-pair</code>.
</p>
<p>
I have generally followed a regular and consistent naming scheme, composing
procedure names from a set of basic lexemes.
</p>
<!--========================================================================-->
<h2><a name="LinearUpdateProcedures">"Linear update" procedures</a></h2>
<p>
Many procedures in this library have "pure" and "linear update" variants. A
"pure" procedure has no side-effects, and in particular does not alter its
arguments in any way. A "linear update" procedure is allowed -- but <em>not</em>
required -- to side-effect its arguments in order to construct its
result. "Linear update" procedures are typically given names ending with an
exclamation point. So, for example, <code>(append! list1 list2)</code> is allowed to
construct its result by simply using <code>set-cdr!</code> to set the cdr of the last pair
of <var>list<sub>1</sub></var> to point to <var>list<sub>2</sub></var>, and then returning <var>list<sub>1</sub></var> (unless <var>list<sub>1</sub></var> is the
empty list, in which case it would simply return <var>list<sub>2</sub></var>). However, <code>append!</code> may
also elect to perform a pure append operation -- this is a legal definition
of <code>append!</code>:
</p>
<pre class="code-example">
(define append! append)
</pre>
<p>
This is why we do not call these procedures "destructive" -- because they
aren't <em>required</em> to be destructive. They are <em>potentially</em> destructive.
</p>
<p>
What this means is that you may only apply linear-update procedures to
values that you know are "dead" -- values that will never be used again
in your program. This must be so, since you can't rely on the value passed
to a linear-update procedure after that procedure has been called. It
might be unchanged; it might be altered.
</p>
<p>
The "linear" in "linear update" doesn't mean "linear time" or "linear space"
or any sort of multiple-of-n kind of meaning. It's a fancy term that
type theorists and pure functional programmers use to describe
systems where you are only allowed to have exactly one reference to each
variable. This provides a guarantee that the value bound to a variable is
bound to no other variable. So when you <em>use</em> a variable in a variable
reference, you "use it up." Knowing that no one else has a pointer to that
value means the a system primitive is free to side-effect its arguments to
produce what is, observationally, a pure-functional result.
</p>
<p>
In the context of this library, "linear update" means you, the programmer,
know there are <em>no other</em> live references to the value passed to the
procedure -- after passing the value to one of these procedures, the
value of the old pointer is indeterminate. Basically, you are licensing
the Scheme implementation to alter the data structure if it feels like
it -- you have declared you don't care either way.
</p>
<p>
You get no help from Scheme in checking that the values you claim are "linear"
really are. So you better get it right. Or play it safe and use the non-!
procedures -- it doesn't do any good to compute quickly if you get the wrong
answer.
</p>
<p>
Why go to all this trouble to define the notion of "linear update" and use it
in a procedure spec, instead of the more common notion of a "destructive"
operation? First, note that destructive list-processing procedures are almost
always used in a linear-update fashion. This is in part required by the
special case of operating upon the empty list, which can't be side-effected.
This means that destructive operators are not pure side-effects -- they have
to return a result. Second, note that code written using linear-update
operators can be trivially ported to a pure, functional subset of Scheme by
simply providing pure implementations of the linear-update operators. Finally,
requiring destructive side-effects ruins opportunities to parallelise these
operations -- and the places where one has taken the trouble to spell out
destructive operations are usually exactly the code one would want a
parallelising compiler to parallelise: the efficiency-critical kernels of the
algorithm. Linear-update operations are easily parallelised. Going with a
linear-update spec doesn't close off these valuable alternative implementation
techniques. This list library is intended as a set of low-level, basic
operators, so we don't want to exclude these possible implementations.
</p>
<p>
The linear-update procedures in this library are
</p>
<div class="indent"><code>
take! drop-right! split-at!
append! concatenate! reverse! append-reverse!
append-map! map!
filter! partition! remove!
take-while! span! break!
delete! alist-delete! delete-duplicates!
lset-union! lset-intersection!
lset-difference! lset-xor! lset-diff+intersection!
</code></div>
<!--========================================================================-->
<h2><a name="ImproperLists">Improper Lists</a></h2>
<p>
Scheme does not properly have a list type, just as C does not have a string
type. Rather, Scheme has a binary-tuple type, from which one can build binary
trees. There is an <em>interpretation</em> of Scheme values that allows one to
treat these trees as lists. Further complications ensue from the fact that
Scheme allows side-effects to these tuples, raising the possibility of lists
of unbounded length, and trees of unbounded depth (that is, circular data
structures).
</p>
<p>
However, there is a simple view of the world of Scheme values that considers
every value to be a list of some sort. that is, every value is either
</p>
<ul>
<li>
a "proper list" -- a finite, nil-terminated list, such as:<br />
<code>(a b c)</code><br />
<code>()</code><br />
<code>(32)</code><br />
</li>
<li>
a "dotted list" -- a finite, non-nil terminated list, such as:<br />
<code>(a b c . d)</code><br />
<code>(x . y)</code><br />
<code>42</code><br />
<code>george</code><br />
</li>
<li>
or a "circular list" -- an infinite, unterminated list.
</li>
</ul>
<p>
Note that the zero-length dotted lists are simply all the non-null, non-pair
values.
</p>
<p>
This view is captured by the predicates <code>proper-list?</code>, <code>dotted-list?</code>, and
<code>circular-list?</code>. List-lib users should note that dotted lists are not commonly
used, and are considered by many Scheme programmers to be an ugly artifact of
Scheme's lack of a true list type. However, dotted lists do play a noticeable
role in the <em>syntax</em> of Scheme, in the "rest" parameters used by n-ary
lambdas: <code>(lambda (x y . rest) ...)</code>.
</p>
<p>
Dotted lists are <em>not</em> fully supported by list-lib. Most procedures are
defined only on proper lists -- that is, finite, nil-terminated lists. The
procedures that will also handle circular or dotted lists are specifically
marked. While this design decision restricts the domain of possible arguments
one can pass to these procedures, it has the benefit of allowing the
procedures to catch the error cases where programmers inadvertently pass
scalar values to a list procedure by accident,
<em>e.g.</em>, by switching the arguments to a procedure call.
</p>
<!--========================================================================-->
<h2><a name="Errors">Errors</a></h2>
<p>
Note that statements of the form "it is an error" merely mean "don't
do that." They are not a guarantee that a conforming implementation will
"catch" such improper use by, for example, raising some kind of exception.
Regrettably, <abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> Scheme requires no firmer guarantee even for basic operators such
as <code>car</code> and <code>cdr</code>, so there's little point in requiring these procedures to do
more. Here is the relevant section of the <abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr>:
</p>
<blockquote>
<p>
When speaking of an error situation, this report uses the phrase "an
error is signalled" to indicate that implementations must detect and
report the error. If such wording does not appear in the discussion
of an error, then implementations are not required to detect or
report the error, though they are encouraged to do so. An error
situation that implementations are not required to detect is usually
referred to simply as "an error."
</p><p>
For example, it is an error for a procedure to be passed an argument
that the procedure is not explicitly specified to handle, even though
such domain errors are seldom mentioned in this report.
Implementations may extend a procedure's domain of definition to
include such arguments.
</p></blockquote>
<!--========================================================================-->
<h2><a name="NotIncludedInThisLibrary">Not included in this library</a></h2>
<p>
The following items are not in this library:
</p>
<ul>
<li>Sort routines
</li><li>Destructuring/pattern-matching macro
</li><li>Tree-processing routines
</li></ul>
<p>
They should have their own <abbr title="Scheme Request for Implementation">SRFI</abbr> specs.
</p>
<!--========================================================================-->
<h2 id="TheProcedures">The procedures</h2>
<p>
In a Scheme system that has a module or package system, these procedures
should be contained in a module named "list-lib".
</p>
<p>
The templates given below obey the following conventions for procedure formals:
</p>
<table>
<tr valign="baseline"><th align="left"> <var>list</var>
</th><td> A proper (finite, nil-terminated) list
</td></tr><tr valign="baseline"><th align="left"> <var>clist</var>
</th><td> A proper or circular list
</td></tr><tr valign="baseline"><th align="left"> <var>flist</var>
</th><td> A finite (proper or dotted) list
</td></tr><tr valign="baseline"><th align="left"> <var>pair</var>
</th><td> A pair
</td></tr><tr valign="baseline">
<th align="left"> <var>x</var>, <var>y</var>, <var>d</var>, <var>a</var>
</th><td> Any value
</td></tr><tr valign="baseline"><th align="left"> <var>object</var>, <var>value</var>
</th><td> Any value
</td></tr><tr valign="baseline"><th align="left"> <var>n</var>, <var>i</var>
</th><td> A natural number (an integer >= 0)
</td></tr><tr valign="baseline"><th align="left"> <var>proc</var>
</th><td> A procedure
</td></tr><tr valign="baseline"><th align="left"> <var>pred</var>
</th><td> A procedure whose return value is treated as a boolean
</td></tr><tr valign="baseline"><th align="left"> <var>=</var>
</th><td> A boolean procedure taking two arguments
</td></tr></table>
<p>
It is an error to pass a circular or dotted list to a procedure not
defined to accept such an argument.
</p>
<!--========================================================================-->
<h2 id="Constructors">Constructors</h2>
<dl>
<!--
==== cons
============================================================================-->
<dt class="proc-def">
<a name="cons"></a>
<code class="proc-def">cons</code> <var>a d -> pair</var>
</dt>
<dd class="proc-def">
<p>
[<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr>]
The primitive constructor. Returns a newly allocated pair whose car is
<var>a</var> and whose cdr is <var>d</var>.
The pair is guaranteed to be different (in the sense of <code>eqv?</code>)
from every existing object.
</p>
<pre class="code-example">
(cons 'a '()) => (a)
(cons '(a) '(b c d)) => ((a) b c d)
(cons "a" '(b c)) => ("a" b c)
(cons 'a 3) => (a . 3)
(cons '(a b) 'c) => ((a b) . c)
</pre>
</dd>
<!--
==== list
============================================================================-->
<dt class="proc-def">
<a name="list"></a>
<code class="proc-def">list</code> <var>object ... -> list</var>
</dt>
<dd class="proc-def">
<p>
[<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr>]
Returns a newly allocated list of its arguments.
</p>
<pre class="code-example">
(list 'a (+ 3 4) 'c) => (a 7 c)
(list) => ()
</pre>
</dd>
<!--
==== xcons
============================================================================-->
<dt class="proc-def">
<a name="xcons"></a>
<code class="proc-def">xcons</code> <var>d a -> pair</var>
</dt>
<dd class="proc-def">
<pre>
(lambda (d a) (cons a d))
</pre>
<p>
Of utility only as a value to be conveniently passed to higher-order
procedures.
</p>
<pre class="code-example">
(xcons '(b c) 'a) => (a b c)
</pre>
<p>
The name stands for "eXchanged CONS."
</p>
</dd>
<!--
==== cons*
============================================================================-->
<dt class="proc-def" id="cons*"><code class="proc-def">cons*</code><var> elt<sub>1</sub> elt<sub>2</sub> ... -> object</var>
</dt>
<dd class="proc-def">
<p>
Like <code>list</code>,
but the last argument provides the tail of the constructed list,
returning
</p>
<div class="indent"><code>
(cons <var>elt<sub>1</sub></var> (cons <var>elt<sub>2</sub></var> (cons ... <var>elt<sub>n</sub></var>)))
</code></div>
<p>
This function is called <code>list*</code> in <a href="#CommonLisp">Common Lisp</a> and about
half of the Schemes that provide it,
and <code>cons*</code> in the other half.
</p>
<pre class="code-example">
(cons* 1 2 3 4) => (1 2 3 . 4)
(cons* 1) => 1
</pre>
</dd>
<!--
==== make-list
============================================================================-->
<dt class="proc-def" id="make-list"> <code class="proc-def">make-list</code> <var>n [fill] -> list</var>
</dt>
<dd class="proc-def">
<p>
Returns an <var>n</var>-element list,
whose elements are all the value <var>fill</var>.
If the <var>fill</var> argument is not given, the elements of the list may
be arbitrary values.
</p>
<pre class="code-example">
(make-list 4 'c) => (c c c c)
</pre>
</dd>
<!--
==== list-tabulate
============================================================================-->
<dt class="proc-def" id="list-tabulate"><code class="proc-def">list-tabulate</code><var> n init-proc -> list</var>
</dt>
<dd class="proc-def">
<p>
Returns an <var>n</var>-element list. Element <var>i</var> of the list, where 0 <= <var>i</var> < <var>n</var>,
is produced by <code>(<var>init-proc</var> <var>i</var>)</code>. No guarantee is made about the dynamic
order in which <var>init-proc</var> is applied to these indices.
</p>
<pre class="code-example">
(list-tabulate 4 values) => (0 1 2 3)
</pre>
</dd>
<!--
==== list-copy
============================================================================-->
<dt class="proc-def" id="list-copy"><code class="proc-def">list-copy</code><var> flist -> flist</var>
</dt>
<dd class="proc-def">
<p>
Copies the spine of the argument.
</p>
</dd>
<!--
==== circular-list
============================================================================-->
<dt class="proc-def" id="circular-list"><code class="proc-def">circular-list</code><var> elt<sub>1</sub> elt<sub>2</sub> ... -> clist</var>
</dt>
<dd class="proc-def">
<p>
Constructs a circular list of the elements.
</p>
<pre class="code-example">
(circular-list 'z 'q) => (z q z q z q ...)
</pre>
</dd>
<!--
==== iota
============================================================================-->
<dt class="proc-def" id="iota"><code class="proc-def">iota</code><var> count [start step] -> list</var>
</dt>
<dd class="proc-def">
<p>
Returns a list containing the elements
</p>
<pre class="code-example">
(<var>start</var> <var>start</var>+<var>step</var> ... <var>start</var>+(<var>count</var>-1)*<var>step</var>)
</pre>
<p>
The <var>start</var> and <var>step</var> parameters default to 0 and 1, respectively.
This procedure takes its name from the APL primitive.
</p>
<pre class="code-example">
(iota 5) => (0 1 2 3 4)
(iota 5 0 -0.1) => (0 -0.1 -0.2 -0.3 -0.4)
</pre>
</dd>
</dl>
<!--========================================================================-->
<h2><a name="Predicates">Predicates</a></h2>
<p>
Note: the predicates <code>proper-list?</code>, <code>circular-list?</code>, and <code>dotted-list?</code>
partition the entire universe of Scheme values.
</p>
<dl>
<!--
==== proper-list?
============================================================================-->
<dt class="proc-def">
<code class="proc-def">proper-list?</code><var> x -> boolean</var>
<a name="proper-list-p"></a>
</dt>
<dd class="proc-def">
<p>
Returns true iff <var>x</var> is a proper list -- a finite, nil-terminated list.
</p>
<p>
More carefully: The empty list is a proper list. A pair whose cdr is a
proper list is also a proper list:
</p>
<pre>
<proper-list> ::= () (Empty proper list)
| (cons <x> <proper-list>) (Proper-list pair)
</pre>
<p>
Note that this definition rules out circular lists. This
function is required to detect this case and return false.
</p>
<p>
Nil-terminated lists are called "proper" lists by <abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> and <a href="#CommonLisp">Common Lisp</a>.
The opposite of proper is improper.
</p>
<p>
<abbr title="Revised^5 Report on Scheme"><a href="#R5RS">R5RS</a></abbr> binds this function to the variable <code>list?</code>.
</p>
<pre>
(not (proper-list? <var>x</var>)) = (or (dotted-list? <var>x</var>) (circular-list? <var>x</var>))
</pre>
</dd>
<!--
==== circular-list?
============================================================================-->
<dt class="proc-def" id="circular-list-p"><code class="proc-def">circular-list?</code><var> x -> boolean</var>
</dt>
<dd class="proc-def">
<p>
True if <var>x</var> is a circular list. A circular list is a value such that
for every <var>n</var> >= 0, cdr<sup><var>n</var></sup>(<var>x</var>) is a pair.
</p>
<p>
Terminology: The opposite of circular is finite.
</p>
<pre>
(not (circular-list? <var>x</var>)) = (or (proper-list? <var>x</var>) (dotted-list? <var>x</var>))
</pre>
</dd>
<!--
==== dotted-list?
============================================================================-->