-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathsrfi-140.html
More file actions
1745 lines (1633 loc) · 72.5 KB
/
srfi-140.html
File metadata and controls
1745 lines (1633 loc) · 72.5 KB
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 PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Immutable Strings</title>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link rel="stylesheet" href="/srfi.css" type="text/css" />
<link href="/favicon.png" rel="icon" sizes="192x192" type="image/png" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css">
div.title h1 { font-size: small; color: blue }
div.title { font-size: xx-large; color: blue; font-weight: bold }
h1 { font-size: x-large; color: blue }
h2 { font-size: large; color: blue }
/* So var inside pre gets same font as var in paragraphs. */
var { font-family: monospace; }
em.non-terminal { }
em.non-termina-def { }
code.literal { font-style: normal; }
code.literal:before { content: "“" }
code.literal:after { content: "”" }
span.proc-def { font-weight: bold }
</style>
</head>
<body>
<div class="title">
<h1>Title</h1>
Immutable Strings
</div>
<h1>Author</h1>
Per Bothner
<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+140+at+srfi+dotschemers+dot+org">srfi-140@<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-140">archive</a>.</p>
<ul>
<li>Received: 2016-07-11</li>
<li>60-day deadline: 2016-09-09</li>
<li>Draft #1 published: 2016-07-11</li>
<li>Draft #2 published: 2016-07-31</li>
<li>Draft #3 published: 2016-08-15</li>
<li>Draft #4 published: 2017-02-01</li>
<li>Draft #5 published: 2017-04-16</li>
<li>Draft #6 published: 2017-04-25</li>
<li>Draft #7 published: 2017-05-09</li>
<li>Draft #8 published: 2017-05-19</li>
<li>Finalized: 2017-05-24</li>
<li>Revised to fix errata:
<ul>
<li>2018-11-28 (Fixed four typos ("(stri 140").)</li>
<li>2019-04-06 (Fixed return type of <code>string-pad</code>, included <code>read-line</code> and <code>read-string</code> among istring-returning procedures from R7RS, and fixed typo in Libraries section.)</li>
<li>2020-03-04 (Add note about accumulation of strings in <code>string-unfold-right</code>.)</ul></li>
</ul>
<h1>Abstract</h1>
<p>This attempts to solve the same issues with R7RS strings raised by
<a href="https://srfi.schemers.org/srfi-135/srfi-135.html">SRFI-135</a>,
but with better integration with the Scheme language.</p>
<p>
We propose to retain the name <dfn>string</dfn> as
the type of sequences of Unicode characters (scalar values).
There are two standard subtypes of string:
<ul>
<li>Immutable strings, also called <dfn>istrings</dfn>, cannot be
modified after they have been created. Calling <code>string-set!</code>
on an istring throws an error.
On the other hand, the core operations <code>string-ref</code> and
<code>string-length</code> are guaranteed to be O(1).
<li>Mutable strings can be modified <q>in-place</q> using
<code>string-set!</code> and other operations.
However, <code>string-ref</code>, <code>string-set!</code>,
or <code>string-length</code> have no performance guarantees.
On many implementation they may take time proportional to the
length of the string.
</ul>
An implementation may support other kinds of strings.
For example on the Java platform it may be reasonable to
consider any instance of <code>java.lang.CharSequence</code> to be a string.
<p>
The main part of the proposal specifies the default bindings of various procedure names,
as might be pre-defined in a REPL. Specifically, some procedures
that traditionally return mutable strings are changed to return istrings.
We later discuss compatibility and other library issues.
<p>
This combines
<a href="https://srfi.schemers.org/srfi-13/srfi-13.html">SRFI-13</a>,
<a href="https://srfi.schemers.org/srfi-135/srfi-135.html">SRFI-135</a>,
and <a href="https://srfi.schemers.org/srfi-118/srfi-118.html">SRFI-118</a>.
<h1>Rationale</h1>
<p>This attempts to solve the same issues with R7RS strings raised by
<a href="https://srfi.schemers.org/srfi-135/srfi-135.html">SRFI-135</a>:
non-guaranteed O(1) indexing, limited sharing, in general the limited
usefulness of mutable strings, especially fixed-size ones.
Our solution is in concept the same, but the goal is better
integration with the Scheme language. Specifically, SRFI-135
proposes new names for types and procedures in a way that is
not integrated with Scheme tradition and existing code.
It also adds a slew of new names for people to learn.
While the relationship between old procedures and SRFI-135 procedures
is natural and straightforward, it still adds a conceptual hurdle and wart
to the Scheme language, complicating teaching and migration.
This specification uses traditional RnRS and SRFI-13 names, but changes
procedures to return istrings, rather than mutable strings.
This may break some existing programs, but it seems worth it:
<ul>
<li>Programs that break seem to be rare. They are also easy to fix:
You can always use <code>string-copy</code> to convert an istring
to a mutable string.</li>
<li>Any breakage is obvious, sigalling an error, rather than subtle
or producing an incorrect result.
<li>Programs that depend on <code>string-set!</code> usually are old
and don't support Unicode well, so could do with a review.
<li>Preserving traditional procedure names means that existing code,
documentation, and teaching materials are valid and automatically
<q>ported</q> to using efficient istrings. In contrast, porting code
to use SRFI-135 texts would be a major pain.
</ul>
<h1>Specification</h1>
<p>
<em>Note:</em> This specification provides very similar functionality
as SRFI-135.
However, what SRFI-135 calls <q>textual</q>, we call plain <q>string</q>.
What SRFI-135 calls <q>text</q>, we call either <q>istring</q>
(in type specifiers) or plain <q>string</q> (in most procedure names).
Specifically,
SRFI-135 procedures that start with <code>textual-</code>
or <code>text-</code>, in this specification start with
plain <code>string-</code>.
Any argument or result type marked as <q>textual</q> is changed to
<q>string</q>, while the type <q>text</q> is changed to <q>istring</q>.
<p>
For example:
<dl><dd><dt class="proc-def">
<code class="proc-def">string-map</code><var> proc string<sub>1</sub> string<sub>2</sub> ... → istring</var>
</dt></dl>
<p>
One exception: <code>make-string</code> returns a
mutable string, not an istring.
<h3 id="Notation">Notation</h3>
<p>
In the following procedure specifications:
<ul>
<li>An <var>istring</var> argument or result is an immutable string.</li>
<li>An <var>mstring</var> argument or result is a mutable string.</li>
<li>A <var>string</var> argument or result is any string (immutable or mutable).</li>
</ul>
<p>
Some procedures are specified as executing in guaranteed O(1) time.
Unless specified, the other procedures may execute in linear time,
using time proportional to the length of the involved string(s).
<h3>String literals</h3>
String literals have type istring.
They have the same syntax as in R7RS (small).
In an implementation that supports <a href="https://srfi.schemers.org/srfi-109/srfi-109.html">SRFI-109</a> string quasi-literals also evaluate to istrings.
<h3>Predicates</h3>
<dl>
<dt class="proc-def" id="string-p">
<code>(<span class="proc-def">string?</span></code><var> obj<code>)</code> → boolean</var></dt>
<dd class="proc-def">
Is <var>obj</var> a string?
Must return true if <code>istring?</code> returns true.
Must execute in O(1) time.
</dd>
</dl>
<dl>
<dt class="proc-def" id="istring-p">
<code>(<span class="proc-def">istring?</span></code><var> obj<code>)</code> → boolean</var>
</dt>
<dd class="proc-def">
Is <var>obj</var> an immutable string, with guaranteed
O(1) performance for <code>string-ref</code> and <code>string-length?</code>
Must execute in O(1) time.
</dd>
</dl>
<dl>
<dt class="proc-def" id="string-null-p">
<code>(<span class="proc-def">string-null?</span></code> <var>string</var><code>)</code> → <var>boolean</var>
<dd class="proc-def">
Is <var>string</var> the empty string?
Same result as <code>(= (string-length <var>string</var>) 0)</code> but
must execute in O(1) time.
</dd>
</dl>
<dl>
<dt class="proc-def" id="string-every">
<code>(<span class="proc-def">string-every</span></code><var> pred string [start end]</var><code>)</code><var> → value</var>
<dt class="proc-def" id="string-any">
<code>(<span class="proc-def">string-any</span></code><var> pred string [start end]</var><code>)</code><var> → value</var>
<dd class="proc-def">
<p>
Checks to see if every/any character in <var>string</var>
satisfies <var>pred</var>,
proceeding from left (index <var>start</var>)
to right (index <var>end</var>).
These procedures are short-circuiting:
if <var>pred</var> returns false, <code>string-every</code>
does not call <var>pred</var> on subsequent characters;
if <var>pred</var> returns true, <code>string-any</code>
does not call <var>pred</var> on subsequent characters.
Both procedures are "witness-generating":
</p>
<ul>
<li> If <code>string-every</code> is given an empty interval
(with <var>start</var> = <var>end</var>),
it returns <code>#t</code>.</li>
<li> If <code>string-every</code> returns true for a non-empty
interval (with <var>start</var> < <var>end</var>),
the returned true value is the one returned by the final call to the
predicate on
<code>(string-ref <var>string</var> (- <var>end</var> 1))</code>.</li>
<li> If <code>string-any</code> returns true,
the returned true value is the one returned by the predicate.</li>
</ul>
<p>
<i>Note:</i>
The names of these procedures do not end with a question mark.
This indicates a general value is returned instead of a simple boolean
(<code>#t</code> or <code>#f</code>).
</p>
</dd>
</dl>
<h3>Conversions</h3>
<dl>
<dt class="proc-defi" id="string2vector">
<dt class="proc-def1">
<code>(<span class="proc-def">string->vector</span></code><var> string [start end]</var><code>)</code><var> → char-vector</var>
</dt>
<dt class="proc-defi" id="string2list">
<code>(<span class="proc-def">string->list</span></code><var> string [start end]</var><code>)</code><var> → char-list</var>
</dt>
<dd class="proc-def">
<code>string->vector</code>,
and <code>string->list</code>
return a newly allocated (unless empty) vector, or list
of the characters that make up the given substring.
</dd>
<dt class="proc-defi" id="vector2string">
<code>(<span class="proc-def">vector->string</span></code><var> char-vector [start end]</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defn" id="list2string">
<code>(<span class="proc-def">list->string</span></code><var> char-list [start end]</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
These procedures return an istring containing the characters of the given
subvector or sublist.
The behavior of the result will not be affected by subsequent mutation
of the vector or list.
</dd>
<dt class="proc-def" id="reverse-list2string">
<code>(<span class="proc-def">reverse-list->string</span></code><var> char-list</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
An efficient implementation of <code>(compose list->string reverse)</code>:
<pre class="code-example">
(reverse-list->string '(#\a #\B #\c)) → "cBa"
</pre>
This is a common idiom in the epilogue of string-processing loops
that accumulate their result using a list in reverse order.
(See also
<code>string-concatenate-reverse</code> for the "chunked" variant.)
</dd>
</dl>
<dl>
<dt class="proc-def1" id="string2utf8">
<code>(<span class="proc-def">string->utf8 </span></code><var> string [start end]</var><code>)</code><var> → bytevector</var>
</dt>
<dt class="proc-defi" id="string2utf16">
<code>(<span class="proc-def">string->utf16 </span></code><var> string [start end]</var><code>)</code><var> → bytevector</var>
</dt>
<dt class="proc-defi" id="string2utf16be">
<code>(<span class="proc-def">string->utf16be</span></code><var> string [start end]</var><code>)</code><var> → bytevector</var>
</dt>
<dt class="proc-defn" id="string2utf16le">
<code>(<span class="proc-def">string->utf16le</span></code><var> string [start end]</var><code>)</code><var> → bytevector</var>
</dt>
<dd class="proc-def">
These procedures return a newly allocated (unless empty)
bytevector containing
a UTF-8 or UTF-16 encoding of the given substring.
<p>
The bytevectors returned by <code>string->utf8</code>,
<code>string->utf16be</code>, and <code>string->utf16le</code>
do not contain a byte-order mark (BOM).
<code>string->utf16be</code> returns a big-endian encoding,
while <code>string->utf16le</code> returns a little-endian
encoding.
</p>
<p>
The bytevectors returned by <code>string->utf16</code>
begin with a BOM that declares an implementation-dependent
endianness.
The latter <em>should</em> match the <code>big-endian</code>
or <code>little-endian</code> identifier returned by the R7RS <code>features</code> procedure.
The bytevector elements following that BOM
encode the given substring using that endianness.
</p>
<p>
<i>Rationale:</i>
These procedures are consistent with the Unicode standard.
Unicode suggests UTF-16 should default to big-endian, but
Microsoft prefers little-endian.
</p>
<!-- Previous drafts were based on the R6RS semantics:
If no <var>endianness</var> argument is passed to
<code>string->utf16</code>, or if <var>endianness</var>
is the symbol <code>big</code>, then the result uses the UTF-16BE
encoding.
If <var>endianness</var> is the symbol <code>little</code>, then
the result uses the UTF-16LE encoding.
It is an error for any other values or symbols to be passed as a
second argument to <code>string->utf16</code> or
<code>utf16->string</code>.
-->
</dd>
<dt class="proc-def1" id="utf82string">
<code>(<span class="proc-def">utf8->string </span></code><var> bytevector [start end]</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defi" id="utf162string">
<code>(<span class="proc-def">utf16->string </span></code><var> bytevector [start end]</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defi" id="utf16be2string">
<code>(<span class="proc-def">utf16be->string</span></code><var> bytevector [start end]</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defn" id="utf16le2string">
<code>(<span class="proc-def">utf16le->string</span></code><var> bytevector [start end]</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
These procedures interpret their <var>bytevector</var> argument as
a UTF-8 or UTF-16 encoding of a sequence of characters,
and return a string containing that sequence.
<p>
The bytevector subrange given to <code>utf16->string</code>
may begin with a byte order mark (BOM); if so, that BOM
determines whether the rest of the subrange is to be
interpreted as big-endian or little-endian; in either case,
the BOM will not become a character in the returned string.
If the subrange does not begin with a BOM, it is decoded using
the same implementation-dependent endianness used by
<code>string->utf16</code>.
</p>
<p>
The <code>utf16be->string</code> and <code>utf16le->string</code>
procedures interpret their inputs as big-endian or little-endian,
respectively. If a BOM is present, it is treated as a normal
character and will become part of the result.
</p>
<p>
It is an error if the bytevector subrange given to
<code>utf8->string</code> contains invalid UTF-8 byte sequences.
For the other three procedures, it is an error if
<code>(- <var>end</var> <var>start</var>)</code> is odd,
or if the bytevector subrange contains invalid UTF-16 byte sequences.
</p>
<!-- Previous drafts were based on the R6RS semantics:
<p>
If no <var>endianness</var> argument is passed to
<code>utf16->string</code>, then the <var>bytevector</var> is
decoded according to UTF-16, which means a UTF-16 byte order mark (BOM)
at the beginning of the <var>bytevector</var> will determine
the endianness, defaulting to big-endian if no BOM is present;
if a BOM is present at the beginning of the <var>bytevector</var>,
it will not be present in the string returned by <code>utf16->string</code>.
If an <var>endianness</var> argument is passed, it should be
the symbol <code>big</code> or the symbol <code>little</code>,
indicating whether the <var>bytevector</var> should be decoded
as UTF-16BE (<code>big</code>) or UTF-16LE (<code>little</code>);
if the <var>mandatory?</var> argument is absent or false, however,
a UTF-16 BOM at the beginning of the <var>bytevector</var> will
override the given <var>endianness</var> and that BOM will not
be present in the string returned by <code>utf16->string</code>.
If <var>mandatory?</var> is true, then a BOM at the beginning
of the <var>bytevector</var> will not override the given
<var>endianness</var>, and will instead be decoded as a regular
character and become the first character of the string returned
by <code>utf16->string</code>.
</p>
<p>
<i>Note:</i>
Passing the symbol <code>big</code> as a second argument to
<code>utf16->string</code>, with no third argument, is
equivalent to calling <code>utf16->string</code> with just
one argument.
Passing a true value as the third argument yields the official
Unicode semantics for UTF-16BE or UTF-16LE (as determined by
the second argument), but Microsoft's preferred semantics is
obtained by omitting the third argument and passing the symbol
<code>little</code> as second argument.
</p>
-->
</dd>
</dl>
<h3>Immutable string constructors</h3>
<dl><dt class="proc-def" id="string">
<code>(<span class="proc-def">string</span></code> <var>char ...</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
Returns a string consisting of the given characters.
</dd>
</dl>
<dl>
<dt class="proc-def" id="string-tabulate">
<code>(<span class="proc-def">string-tabulate</span></code><var> proc len</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
<var>Proc</var> is a procedure that accepts an exact integer
as its argument and returns a character.
Constructs a string of size <var>len</var> by calling <var>proc</var>
on each value from 0 (inclusive) to <var>len</var> (exclusive)
to produce the corresponding element of the string.
The order in which <var>proc</var> is called on those indexes is not
specified.
<p>
<i>Rationale:</i>
Although <code>string-unfold</code> is more general,
<code>string-tabulate</code> is likely to run faster
for the common special case it implements.
</p>
</dd>
<dt class="proc-def" id="string-unfold">
<code>(<span class="proc-def">string-unfold</span></code> <var> stop? mapper successor seed [base make-final]</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-def" id="string-unfold-right">
<code>(<span class="proc-def">string-unfold-right</span></code> <var> stop? mapper successor seed [base make-final]</var><code>)</code><var> → istring</var>
<dd class="proc-def">
This is a fundamental constructor for strings.
<ul>
<li> <var>successor</var> is used to generate a series of "seed"
values from the initial seed:
<div class=inset>
<var>seed</var>, (<var>successor</var> <var>seed</var>),
(<var>successor<sup>2</sup></var> <var>seed</var>),
(<var>successor<sup>3</sup></var> <var>seed</var>), ...
</div>
</li>
<li> <var>stop?</var> tells us when to stop — when it returns
true when applied to one of these seed values.</li>
<li> <var>mapper</var> maps each seed value to the corresponding character(s)
in the result string, which are assembled into that string in left-to-right
order.
It is an error for <var>mapper</var> to return anything
other than a character or string.</li>
<li> <var>base</var> is the optional initial/leftmost portion of
the constructed string, which defaults to the empty string <code>""</code>.
It is an error if <var>base</var> is anything other than a character or string.</li>
<li> <var>make-final</var> is applied to the terminal seed value
(on which <var>stop?</var> returns
true) to produce the final/rightmost portion of the constructed string.
It defaults to <code>(lambda (x) (string))</code>.
It is an error for <var>make-final</var> to return anything other
than a character or string.</li>
</ul>
<p><code>string-unfold-right</code> is the same as <code>string-unfold</code>
except the results of <var>mapper</var> are assembled into the string
in right-to-left order,
<var>base</var> is the optional rightmost portion of the constructed string,
and <var>make-final</var> produces the leftmost portion of the
constructed string. If <var>mapper</var> returns a string, the string
is prepended to the constructed string (without reversal). For example:
<pre class="code-example">
(string-unfold-right null?
(lambda (x) (string #\[ (car x) #\]))
cdr
'(#\a #\b #\c))
= "[c][b][a]"
</pre>
<p>
<code>string-unfold</code> is a fairly powerful string constructor.
You can use it to
convert a list to a string, read a port into a string, reverse a string,
copy a string, and so forth. Examples:
</p>
<pre class="code-example">
(port->string p) = (string-unfold eof-object?
values
(lambda (x) (read-char p))
(read-char p))
(list->string lis) = (string-unfold null? car cdr lis)
(string-tabulate f size) = (string-unfold (lambda (i) (= i size)) f add1 0)
</pre>
<p>
To map <var>f</var> over a list <var>lis</var>, producing a string:
<pre class="code-example">
(string-unfold null? (compose f car) cdr lis)
</pre>
<p>
Interested functional programmers may enjoy noting that
<code>string-fold-right</code>
and <code>string-unfold</code> are in some sense inverses.
That is, given operations
<var>knull?</var>, <var>kar</var><var>, kdr</var>, <var>kons</var>,
and <var>knil</var> satisfying
</p>
<pre class="code-example">
(<var>kons</var> (<var>kar</var> x) (<var>kdr</var> x)) = x and (<var>knull?</var> <var>knil</var>) = #t
</pre>
<p>
then
</p>
<pre class="code-example">
(string-fold-right <var>kons</var> <var>knil</var> (string-unfold <var>knull?</var> <var>kar</var> <var>kdr</var> <var>x</var>)) = <var>x</var>
</pre>
and
<pre class="code-example">
(string-unfold <var>knull?</var> <var>kar</var> <var>kdr</var> (string-fold-right <var>kons</var> <var>knil</var> <var>string</var>)) = <var>string</var>.
</pre>
<p>
This combinator pattern is sometimes called an "anamorphism."
</p>
<p>
<i>Note:</i> Implementations should not allow the size of strings created
by <code>string-unfold</code> to be limited by limits on stack size.
</p>
</dd>
</dl>
<p>For functionality similar to <a href="#make-string"><code>make-string</code></a>,
but returning an immutable string,
you can use <a href="#string-repeat"><code>string-repeat</code></a>.
<h3>Selection</h3>
<dl>
<dt class="proc-def" id="string-length">
<code>(<span class="proc-def">string-length</span></code><var> string</var><code>)</code><var> → len</var>
</dt>
<dt class="proc-def" id="string-ref">
<code>(<span class="proc-def">string-ref</span></code><var> string idx</var><code>)</code><var> → char</var>
</dt>
<dd>As in R7RS.
However, if the <var>string</var> is an istring, both must execute
in constant time; otherwise they may execute in time proportional to
the length of <var>string</var>.
</dd>
<dt class="proc-def" id="substring">
<code>(<span class="proc-def">substring</span></code><var> string start end</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
This procedure returns a istring containing the characters of
<var>string</var> starting with index <var>start</var>
(inclusive) and ending with index <var>end</var> (exclusive).
<p>
If <var>string</var> is a mutable string, then that string does not
share any
storage with the result, so subsequent mutation of that string
will not affect the result returned by <code>substring</code>.
When the first argument is an istring,
implementations are encouraged to return a result that shares storage with
that istring,
to whatever extent sharing is possible while maintaining some
small fixed bound on the ratio of storage used by the shared
representation divided by the storage that would be used by
an unshared representation.
In particular, these procedures should just return their first
argument when that argument is an istring, <var>start</var> is 0, and
<var>end</var> is the length of that string.
</p>
<p>For the functionality of <code>substring</code> with guaranteed no sharing
use <code>xsubstring</code> for an immutable result,
or <code>string-copy</code> for a mutable result.
</dd>
<dt class="proc-def1" id="string-take">
<code>(<span class="proc-def">string-take</span> </code><var> string nchars</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defi" id="string-drop">
<code>(<span class="proc-def">string-drop</span> </code><var> string nchars</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defi" id="string-take-right">
<code>(<span class="proc-def">string-take-right</span></code><var> string nchars</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defn" id="string-drop-right">
<code>(<span class="proc-def">string-drop-right</span></code><var> string nchars</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
<code>string-take</code> returns an immutable string containing the first
<var>nchars</var> of <var>string</var>;
<code>string-drop</code> returns a string containing all but the
first <var>nchars</var> of <var>string</var>.
<code>string-take-right</code> returns a string containing the
last <var>nchars</var> of <var>string</var>;
<code>string-drop-right</code> returns a string containing all
but the last <var>nchars</var> of <var>string</var>.
<p>
Subsequent mutation of the argument string
will not affect the istring returned by these procedures.
If <var>string</var> is an istring, implementations are
encouraged to return a result that shares storage with that string
(which is easily accomplished by using <code>substring</code> to
create the result).
</p>
<pre class="code-example">
(string-take "Pete Szilagyi" 6) => "Pete S"
(string-drop "Pete Szilagyi" 6) => "zilagyi"
(string-take-right "Beta rules" 5) => "rules"
(string-drop-right "Beta rules" 5) => "Beta "
</pre>
<p>
It is an error to take or drop more characters than are in the string:
</p>
<pre class="code-example">
(string-take "foo" 37) => <em>error</em>
</pre>
</dd>
</dl>
<dl>
<dt class="proc-def1" id="string-pad">
<code>(<span class="proc-def">string-pad </span></code><var> string len [char start end]</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defn" id="string-pad-right">
<code>(<span class="proc-def">string-pad-right</span></code><var> string len [char start end]</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
Returns an istring of length <var>len</var> comprised of the characters
drawn from the given subrange of <var>string</var>.
The result is padded on the left (right) by as many occurrences
of the character <var>char</var> (which defaults to <code>#\space</code>) as needed.
If <var>string</var> has more
than <var>len</var> chars, it is truncated on the left (right)
to length <var>len</var>.
<pre class="code-example">
(string-pad "325" 5) => " 325"
(string-pad "71325" 5) => "71325"
(string-pad "8871325" 5) => "71325"
</pre>
</dd>
</dl>
<!--
==== string-trim string-trim-right string-trim-both
============================================================================-->
<dl>
<dt class="proc-def1">
<code>(<span class="proc-def" id="string-trim">string-trim </span></code><var> string [pred start end]</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defi">
<code>(<span class="proc-def" id="string-trim-right">string-trim-right</span></code><var> string [pred start end]</var><code>)</code><var> → istring</var>
</dt>
<dt class="proc-defi">
<code>(<span class="proc-def" id="string-trim-both">string-trim-both </span></code><var> string [pred start end]</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-defn">
Returns a string obtained from the given subrange of <var>string</var>
by skipping
over all characters on the left / on the right /
on both sides that satisfy the second argument <var>pred</var>:
<var>pred</var> defaults to <code>char-whitespace?</code>.
<pre class="code-example">
(string-trim-both " The outlook wasn't brilliant, \n\r")
=> "The outlook wasn't brilliant,"
</pre>
<p><i>Note:</i> It would be more natural to rename <code>string-trim</code> to <code>string-trim-left</code>,
and possibly rename <code>string-trim-both</code> to <code>string-trim</code>,
but SRFI-13 uses the specified names.
</dd>
</dl>
<h3>Replacement</h3>
<dl>
<dt class="proc-def" id="string-replace">
<code>(<span class="proc-def">string-replace</span></code><var> string<sub>1</sub> string<sub>2</sub> start<sub>1</sub> end<sub>1</sub> [start<sub>2</sub> end<sub>2</sub>]</var><code>)</code><var> → istring</var>
</dt>
<dd class="proc-def">
Returns
<pre class="code-example">
(string-append (substring <var>string<sub>1</sub></var> 0 <var>start<sub>1</sub></var>)
(substring <var>string<sub>2</sub></var> <var>start<sub>2</sub></var> <var>end<sub>2</sub></var>)
(substring <var>string<sub>1</sub></var> <var>end<sub>1</sub></var> (string-length <var>string<sub>1</sub></var>)))
</pre>
<p>
That is, the segment of characters in <var>string<sub>1</sub></var>
from <var>start<sub>1</sub></var> to <var>end<sub>1</sub></var>
is replaced by the segment of characters in <var>string<sub>2</sub></var>
from <var>start<sub>2</sub></var> to <var>end<sub>2</sub></var>.
If <var>start<sub>1</sub></var>=<var>end<sub>1</sub></var>, this simply splices
the characters drawn from <var>string<sub>2</sub></var> into <var>string<sub>1</sub></var>
at that position.
</p>
<p>
Examples:
</p>
<pre class="code-example">
(string-replace "The TCL programmer endured daily ridicule."
"another miserable perl drone" 4 7 8 22)
=> "The miserable perl programmer endured daily ridicule."
(string-replace "It's easy to code it up in Scheme." "lots of fun" 5 9)
=> "It's lots of fun to code it up in Scheme."
(define (string-insert s i t) (string-replace s t i i))
(string-insert "It's easy to code it up in Scheme." 5 "really ")
=> "It's really easy to code it up in Scheme."
(define (string-set s i c) (string-replace s (string c) i (+ i 1)))
(string-set "String-ref runs in O(n) time." 19 #\1)
=> "String-ref runs in O(1) time."
</pre>
</dd>
</dl>
<h3>Comparison</h3>
<dl><dt class="proc-def" id="string-equal-p">
<code>(<span class="proc-def">string=?</span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dt class="proc-defi" id="string-less-p">
<code>(<span class="proc-def">string<? </span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dt class="proc-defi" id="string-greater-p">
<code>(<span class="proc-def">string>? </span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dt class="proc-def" id="string-leq-p">
<code>(<span class="proc-def">string<=?</span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dt class="proc-defn" id="string-geq-p">
<code>(<span class="proc-def">string>=?</span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dt class="proc-def" id="string-ci-equal-p">
<code>(<span class="proc-def">string-ci=?</span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dt class="proc-def1" id="string-ci-less-p">
<code>(<span class="proc-def">string-ci<? </span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dt class="proc-defi" id="string-ci-greater-p">
<code>(<span class="proc-def">string-ci>? </span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dt class="proc-defi" id="string-ci-leq-p">
<code>(<span class="proc-def">string-ci<=?</span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ..<code>)</code>. → boolean</var>
</dt>
<dt class="proc-defn" id="string-ci-geq-p">
<code>(<span class="proc-def">string-ci>=?</span></code><var> string<sub>1</sub> string<sub>2</sub> string<sub>3</sub> ...<code>)</code> → boolean</var>
</dt>
<dd>As in R7RS.</dd>
</dl>
<h3>Prefixes & suffixes</h3>
<dl>
<!--
==== string-prefix-length string-suffix-length
============================================================================-->
<dt class="proc-def1" id="string-prefix-length">
<code>(<span class="proc-def">string-prefix-length</span></code><var> string<sub>1</sub> string<sub>2</sub> [start<sub>1</sub> end<sub>1</sub> start<sub>2</sub> end<sub>2</sub>]<code>)</code> → integer</var>
</dt>
<dt class="proc-defn" id="string-suffix-length">
<code>(<span class="proc-def">string-suffix-length</span></code><var> string<sub>1</sub> string<sub>2</sub> [start<sub>1</sub> end<sub>1</sub> start<sub>2</sub> end<sub>2</sub>]<code>)</code> → integer</var>
</dt>
<dd class="proc-def">
Return the length of the longest common prefix/suffix of
<var>string<sub>1</sub></var> and <var>string<sub>2</sub></var>.
For prefixes, this is equivalent to their "mismatch index"
(relative to the start indexes).
<p>
The optional start/end indexes restrict the comparison to the indicated
substrings of <var>string<sub>1</sub></var> and <var>string<sub>2</sub></var>.
</p>
</dd>
<!--
==== string-prefix? string-suffix?
============================================================================-->
<dt class="proc-def1" id="string-prefix-p">
<code>(<span class="proc-def">string-prefix?</span></code><var> string<sub>1</sub> string<sub>2</sub> [start<sub>1</sub> end<sub>1</sub> start<sub>2</sub> end<sub>2</sub>]<code>)</code> → boolean</var>
</dt>
<dt class="proc-defn" id="string-suffix-p">
<code>(<span class="proc-def">string-suffix?</span></code><var> string<sub>1</sub> string<sub>2</sub> [start<sub>1</sub> end<sub>1</sub> start<sub>2</sub> end<sub>2</sub>]<code>)</code> → boolean</var>
</dt>
<dd class="proc-def">
Is <var>string<sub>1</sub></var> a prefix/suffix of <var>string<sub>2</sub></var>?
<p>
The optional start/end indexes restrict the comparison to the indicated
substrings of <var>string<sub>1</sub></var> and <var>string<sub>2</sub></var>.
</p>
</dd>
</dl>
<h3>Searching</h3>
<dl>
<dt class="proc-def1" id="string-index">
<code>(<span class="proc-def">string-index</span> </code><var> string pred [start end]<code>)</code> → idx-or-false</var>
</dt>
<dt class="proc-defi" id="string-index-right">
<code>(<span class="proc-def">string-index-right</span></code><var> string pred [start end]<code>)</code> → idx-or-false</var>
</dt>
<dt class="proc-defi" id="string-skip">
<code>(<span class="proc-def">string-skip</span> </code><var> string pred [start end]<code>)</code> → idx-or-false</var>
</dt>
<dt class="proc-defn" id="string-skip-right">
<code>(<span class="proc-def">string-skip-right</span> </code><var> string pred [start end]<code>)</code> → idx-or-false</var>
</dt>
<dd class="proc-def">
<code>string-index</code> searches through the given substring
from the left, returning the index of the leftmost character
satisfying the predicate <var>pred</var>.
<code>string-index-right</code> searches from the
right, returning the index of the rightmost character
satisfying the predicate <var>pred</var>.
If no match is found, these procedures return <code>#f</code>.
<p>
<i>Rationale:</i>
The SRFI 130 analogues of these procedures return cursors,
even when no match is found, and
SRFI 130's <code>string-index-right</code> returns the <em>successor</em>
of the cursor for the first character that satisfies the predicate.
As there are no cursors in this SRFI, it seems best to follow the
more intuitive and long-standing precedent set by SRFI 13.
</p>
<p>
The <var>start</var> and <var>end</var> arguments specify the
beginning and end of the search; the valid indexes relevant to
the search include <var>start</var> but exclude <var>end</var>.
Beware of "fencepost" errors: when searching right-to-left,
the first index considered is
<code>(- <var>end</var> 1)</code>,
whereas when searching left-to-right, the first index considered is
<var>start</var>.
That is, the start/end indexes describe the same half-open interval
[<var>start</var>,<var>end</var>) in these procedures that they do
in all other procedures specified by this SRFI.
</p>
<p>
The skip functions are similar, but use the complement of the criterion:
they search for the first char that <em>doesn't</em> satisfy
<var>pred</var>.
To skip over initial whitespace, for example, say
</p>
<pre class="code-example">
(substring string
(or (string-skip string char-whitespace?)
(string-length string))
(string-length string))
</pre>
<p>
These functions can be trivially composed with <code>string-take</code> and
<code>string-drop</code> to produce take-while, drop-while, span, and break
procedures without loss of efficiency.
</p>
<p><em>Note:</em> SRFI-13 and Guile generalize <var>pred</var> to
<var>char_pred</var>,
which can be a predicate, a character, or a character set.
This is an optional extension.
</dd>
</dl>
<!--
==== string-contains string-contains-right
============================================================================-->
<dl>
<dt class="proc-def1" id="string-contains">
<code>(<span class="proc-def">string-contains</span> </code><var> string<sub>1</sub> string<sub>2</sub> [start<sub>1</sub> end<sub>1</sub> start<sub>2</sub> end<sub>2</sub>]<code>)</code> → idx-or-false</var>
</dt>
<dt class="proc-defn" id="string-contains-right">
<code>(<span class="proc-def">string-contains-right</span></code><var> string<sub>1</sub> string<sub>2</sub> [start<sub>1</sub> end<sub>1</sub> start<sub>2</sub> end<sub>2</sub>]<code>)</code> → idx-or-false</var>
</dt>
<dd class="proc-def">
Does the substring of <var>string<sub>1</sub></var>
specified by <var>start<sub>1</sub></var> and <var>end<sub>1</sub></var>
contain the sequence of characters given by the substring of <var>string<sub>2</sub></var>
specified by <var>start<sub>2</sub></var> and <var>end<sub>2</sub></var>?
<p>
Returns <code>#f</code> if there is no match.
If <var>start<sub>2</sub></var> = <var>end<sub>2</sub></var>,
<code>string-contains</code> returns <var>start<sub>1</sub></var> but
<code>string-contains-right</code> returns <var>end<sub>1</sub></var>.
Otherwise returns the index in <var>string<sub>1</sub></var>
for the first character of the first/last match;
that index lies within the half-open interval
[<var>start<sub>1</sub></var>,<var>end<sub>1</sub></var>),
and the match lies entirely within the
[<var>start<sub>1</sub></var>,<var>end<sub>1</sub></var>) range of <var>string<sub>1</sub></var>.
</p>
<pre class="code-example">
(string-contains "eek -- what a geek." "ee" 12 18) ; Searches "a geek"
=> 15
</pre>
<p>
<i>Note:</i>
The names of these procedures do not end with a question mark.
This indicates a useful value is returned when there is a match.
</p>
</dd>
</dl>
<h3>Case conversion</h3>
<dl>
<dt class="proc-def1" id="string-upcase">
<code>(<span class="proc-def">string-upcase</span> </code><var> string<code>)</code> → istring</var>
</dt>
<dt class="proc-defi" id="string-downcase">
<code>(<span class="proc-def">string-downcase</span></code><var> string<code>)</code> → istring</var>
</dt>
<dt class="proc-defi" id="string-foldcase">
<code>(<span class="proc-def">string-foldcase</span></code><var> string<code>)</code> → istring</var>
</dt>
<dt class="proc-defn" id="string-titlecase">
<code>(<span class="proc-def">string-titlecase</span></code><var> string<code>)</code> → istring</var>
</dt>
<dd class="proc-def">
These procedures return the string obtained by applying
Unicode's full uppercasing, lowercasing, case-folding, or
title-casing algorithms
to their argument. In some cases, the length of the result may
be different from the length of the argument.
If the result is equal to the argument in the sense of <code>string=?</code>,
<em>and</em> the argument is immutable, then that argument may be returned.
Note that language-sensitive mappings and foldings are not used.
<p>
The results are the same as the R7RS procedures, but as immutable strings.
</dd>
</dl>
<h3>Concatenation</h3>
<dl>
<!--
==== string-append
============================================================================-->
<dt class="proc-def" id="string-append">
<code>(<span class="proc-def">string-append</span></code><var> string ...<code>)</code> → istring</var>
</dt>
<dd class="proc-def">
Returns a string whose sequence of characters is the concatenation
of the sequences of characters in the given arguments.
</dd>
<!--
==== string-concatenate
============================================================================-->
<dt class="proc-def" id="string-concatenate">
<code>(<span class="proc-def">string-concatenate</span></code><var> string-list<code>)</code> → istring</var>
</dt>
<dd class="proc-def">
Concatenates the elements of <code>string-list</code> together
into a single string.
<p>
If any elements of <var>string-list</var> are mutable strings,
then those strings do not share any storage with the result,
so subsequent mutation of those string
will not affect the string returned by this procedure.
Implementations are
encouraged to return a result that shares storage with some of
the strings in the list if that sharing would be space-efficient.
</p>
<p>
<i>Rationale:</i>
Some implementations of Scheme
limit the number of arguments that may be passed to an n-ary procedure,
so the <code>(apply string-append <var>string-list</var>)</code> idiom,
which is otherwise equivalent to using this procedure, is not as
portable.
</p>
</dd>
<!--
==== string-concatenate-reverse
============================================================================-->
<dt class="proc-def1" id="string-concatenate-reverse">
<code>(<span class="proc-def">string-concatenate-reverse</span></code><var> string-list [final-string [end]]<code>)</code> → istring</var>
</dt>
<dd class="proc-def">
With no optional arguments, calling this procedure is equivalent to