-
Notifications
You must be signed in to change notification settings - Fork 983
/
release_notes.stex
3760 lines (2977 loc) · 161 KB
/
release_notes.stex
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
\documentclass{releasenotes}
\thisversion{Version 9.9.9}
\thatversion{Version 8.4}
\pubmonth{September}
\pubyear{2023}
\iflatex
\usepackage{enumitem}
\setitemize{noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt}
\newenvironment{itemizeC}%
{\begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt]}%
{\end{itemize}}
\fi
\ifhtml
\newenvironment{itemizeC}{\begin{itemize}}{\end{itemize}}
\fi
\begin{document}
\maketitle
% \tableofcontents
\section{Overview}
This document outlines the changes made to {\ChezScheme} for
{\thisversion} since {\thatversion}.
{\thisversion} is supported for the following platforms.
The Chez Scheme machine type (returned by the \scheme{machine-type}
procedure) is given in parentheses.
\begin{itemize}
\item Linux
\begin{itemizeC}
\item x86, nonthreaded (i3le) and threaded (ti3le)
\item x86\_64, nonthreaded (a6le) and threaded (ta6le)
\item AArch64 including Android, nonthreaded (arm64le) and threaded (tarm64le)
\item ARMv6 (32-bit) including Android, nonthreaded (arm32le) and threaded (tarm32le)
\item RV64G (64-bit RISC-V), nonthreaded (rv64le) and threaded (trv64le)
\item LoongArch64 (64-bit LoongArch), nonthreaded (la64le) and threaded (tla64le)
\item PowerPC (32-bit), nonthreaded (ppc32le) and threaded (tppc32le)
\end{itemizeC}
\item Mac OS
\begin{itemizeC}
\item x86, nonthreaded (i3osx) and threaded (ti3osx)
\item x86\_64, nonthreaded (a6osx) and threaded (ta6osx)
\item AArch64 and iOS, nonthreaded (arm64osx) and threaded (tarm64osx)
\item PowerPC (32-bit) (ppc2osx) and threaded (tppc32osx)
\end{itemizeC}
\item Windows
\begin{itemizeC}
\item x86, nonthreaded (i3nt) and threaded (ti3nt)
\item Windows x86\_64, nonthreaded (a6nt) and threaded (ta6nt)
\item AArch64, nonthreaded (arm64nt) and threaded (tarm64nt)
\end{itemizeC}
\item OpenBSD
\begin{itemizeC}
\item x86, nonthreaded (i3ob) and threaded (ti3ob)
\item x86\_64, nonthreaded (a6ob) and threaded (ta6ob)
\item AArch64, nonthreaded (arm64ob) and threaded (tarm64ob)
\item ARMv6 (32-bit), nonthreaded (arm32ob) and threaded (tarm32ob)
\item PowerPC (32-bit), nonthreaded (ppc32ob) and threaded (tppc32ob)
\end{itemizeC}
\item FreeBSD
\begin{itemizeC}
\item x86, nonthreaded (i3fb) and threaded (ti3fb)
\item x86\_64, nonthreaded (a6fb) and threaded (ta6fb)
\item AArch64, nonthreaded (arm64fb) and threaded (tarm64fb)
\item ARMv6 (32-bit), nonthreaded (arm32fb) and threaded (tarm32fb)
\item PowerPC (32-bit), nonthreaded (ppc32fb) and threaded (tppc32fb)
\end{itemizeC}
\item NetBSD
\begin{itemizeC}
\item x86, nonthreaded (i3nb) and threaded (ti3nb)
\item x86\_64, nonthreaded (a6nb) and threaded (ta6nb)
\item AArch64, nonthreaded (arm64nb) and threaded (tarm64nb)
\item ARMv6 (32-bit), nonthreaded (arm32nb) and threaded (tarm32nb)
\item PowerPC (32-bit), nonthreaded (ppc32nb) and threaded (tppc32nb)
\end{itemizeC}
\item GNU Hurd
\begin{itemizeC}
\item x86, nonthreaded (i3gnu) and threaded (ti3gnu)
\end{itemizeC}
\item OpenSolaris
\begin{itemizeC}
\item x86, nonthreaded (i3s2) and threaded (ti3s2)
\item x86\_64, nonthreaded (a6s2) and threaded (ta6s2)
\end{itemizeC}
\item Other platforms
\begin{itemizeC}
\item bytecode interpretation (pb, tpb, pb32l, tpb32l, pb32b, tpb32b, pb64l, tpb64l, pb64b, tpb64b)
\end{itemizeC}
\end{itemize}
This document contains three sections describing significant
(1) \href[static]{section:functionality}{functionality changes},
(2) \href[static]{section:bugfixes}{bugs fixed}, and
(3) \href[static]{section:performance}{performance enhancements}.
A version number listed in parentheses in the header for a change
indicates the first minor release or internal prerelease to support
the change.
More information on {\ChezScheme} and {\PetiteChezScheme} can
\scheme{be} found at \hyperlink{http://www.scheme.com/}{http://www.scheme.com},
and extensive documentation is available in
\TSPL{4}{th} (available directly from MIT Press or from online and local retailers)
and the \CSUG{9}.
Online versions of both books can be found at
\hyperlink{http://www.scheme.com/}{http://www.scheme.com}.
%-----------------------------------------------------------------------------
\section{Functionality Changes}\label{section:functionality}
\subsection{New supported platforms and portable bytecode (9.9.9)}
AArch64 (64-bit Arm), RV64G (64-bit RISC-V), and LoongArch64 architectures are
supported. Threads are supported on architectures with weak memory
models while preserving the safety guarantee described in the
documentation for variables and primitive datatypes.
The pb (``portable bytecode'') machine type corresponds to a virtual
machine that the Chez Scheme kernel can interpret on practically any
desktop platform. This machine type is used to enable bootstrapping on
all native-code platforms using a single set of boot files. The pb
machine type is also used to support platforms for which Chez Scheme
does not have a supported native-code generator. For the latter use,
the pb32l, pb32b, pb64l, and pb64b machine types specialize the
interpreter to a word size and endianness, which improves performance.
For example, pb32l is a suitable machine type for compiling to
WebAssembly via Emscripten. Each pb variant has a corresponding
threaded variant: tpb, tpb32l, tpb32b, tpb64l, and tpb64b.
The \scheme{pbchunk-convert-file} procedure can convert sequences of
static pb bytecode into C code. The generated C code can be compiled
and linked with the Chez Scheme kernel to reduce the overhead of
bytecode interpretation. In particular, since Chez Scheme is mostly
written in Chez Scheme, a pbchunk conversion of its boot files
improves performance of primitives and compilation.
\subsection{Threaded default and build system changes (9.9.9)}
Running \scheme{configure} assumes a threaded target machine type,
unless \scheme{--nothreads} or a non-threaded machine type is
specified.
The build system mostly uses Zuo instead of Make, but the
\scheme{configure} script continues to generate wrapper makefiles, so
that there's no difference for most users who build from source and do
not modify Chez Scheme. The build process on Windows has changed so
that Unix-style tools are not required, but using Unix-style tools to
compile with MinGW is supported.
The Chez Scheme sources no longer include boot files for multiple
platforms. Instead, a single set of pb boot files is normally used to
build on any platform. This change makes an initial build of Chez
Scheme slower, but it makes the build process consistent across all
supported platforms and enables a much smaller source size.
Alternatively, Chez Scheme can be bootstrapped from an older version
of Chez Scheme (9.5.4 or later) using the \scheme{re.boot} makefile
target.
The new \scheme{scheme-build-number} function complements
\scheme{scheme-version-number}, adding an extra level of versioning
during development. The \scheme{scheme-build-number} procedure always
returns zero for a released version of Chez Scheme.
\subsection{Compiler improvements (9.9.9)}\label{sec:unbox-floats}
The compiler generates code that locally unboxes floating-point
operations, so that compositions of floating-point operations can be
much faster.
The compiler infers information about the type of value produced
by an expression, and it uses that information to eliminate run-time
checks or conditionals. For example, within
\scheme{(if (flonum? x) \var{E1} \var{E2})},
assuming that the variable \scheme{x} is never
mutated, then it holds a flonum value within \var{E1}, so
arithmetic can be specialized to flonum operations. Type inference
requires an additional pass for compilation, but when compiling in
safe mode, the pass tends to more than pay for itself; reduced checks
and error handling create less work for later compilation passes.
Even when many checks are removed, run-time performance may improve
only modestly on modern hardware, since the removed branches are
perfectly predictable. Inference can be disabled by setting
\scheme{enable-type-recovery} to \scheme{#f}.
The compiler can infer more than previously about procedures that
always return a value or that never return (because they raise a
noncontinuable exception). The compiler will no longer move an
expression from a non-tail position to a tail position if that
movement could be detected with continuation marks (see
Section~\ref{sec:cont-marks}), and it will not change a program in a
way that discards an error due to returning multiple values to a
single-value context. The \scheme{assert-unreachable} procedure always
reports an error in safe mode, but it in unsafe mode, it must never be
called; the claim that some code is unreachable propagates backward to
remove other code that must also be unreachable, and even drop
conditionals that must always go the other way to avoid unreachable
code. A macro expansion might use \scheme{assert-unreachable} to
indicate that unsafe mode can assume that a check succeeded and
eliminate the check, for example.
The compiler consistently ``lifts'' procedures: When a procedure has
only known call sites, refers to only immutable variables bound
outside the procedure, and has only call site within the scope of
those variables, then variables used by the procedure are converted to
arguments, and call sites are converted to supply the variables as
arguments. As a result, nested procedure definitions can be used more
freely without a potential cost from closure allocation. There are
programs where forming a closure would be faster, but consistent
lifting is almost always faster in practice.
Cross-library inlining can apply to a procedure that is exported
from a library (explicitly or implicitly) and whose body refers to
another procedure or other variable that is also exported (explicitly
or implicitly).
The compiler reduces code size by using a more compact representation
for most call-return sites and by using a more compact dispatch to
interrupt checking in most cases.
The internal representation of record types has changed so that a
record-type predicate is a constant-time operation, instead of
proportional to the subtype depth.
\subsection{Garbage-collector improvements (9.9.9)}
Garbage collection takes advantage of machine parallelism. Parallel
collection is automatically enabled when a program has multiple Scheme
threads active at the point that a garbage collection starts, but
parallel collection can benefit from a hint about which threads are
most relevant as allocators (see Section~\ref{sec:threads}).
The garbage collector uses a hybrid mark--copy algorithm, which
can improve performance for large objects and long-lived objects
compared to a pure copying collector. The
\scheme{in-place-minimum-generation} parameter tunes the hybrid by
selecting the youngest generation at which marking is used.
The \scheme{collect-maximum-generation-threshold-factor} parameter is
used by \scheme{collect} when called with no arguments. In the case
that the maximum generation would be collected based on the gc-trip
counter, it is collected only when the total memory use is at least $k$
times the memory use just after the most recent collection of the maximum
generation, where the parameter's value is $k$. The default value of 2
helps the collector adapt to the scenario that a program has much more
long-lived data than short-lived data, and where the program does not
explicitly promote its long-lived data to the static generation.
Setting the parameter to 0 makes \scheme{collect} behave as in
previous versions of Chez Scheme.
See also Sections~\ref{sec:gc-reflect} and \ref{sec:ffi-storage} for
related new functionality.
\subsection{Continuation marks (9.9.9)}\label{sec:cont-marks}
\emph{Continuation marks} add key--value information to continuations.
The \scheme{with-continuation-mark} form associates a key--value pair
to the current continuation, replacing any same-keyed mark already
associated to the immediate continuation, and adding to marks
associated with continuations that the current continuation extends.
Inspect marks with these functions:
\schemedisplay
current-continuation-marks
continuation-next-marks
continuation-marks-first
continuation-marks->list
continuation-marks->iterator
call-with-immediate-continuation-mark
continuation-marks?
\endschemedisplay
The \scheme{call-in-continuation} function can invoke a continuation
similar to calling a procedure as a function, but instead of a value
to deliver to the continuation, it takes a procedure of no arguments
to call within the continuation.
\subsection{New fixnum operations (9.9.9)}
New operations support common bit-related operations on fixnums:
\schemedisplay
fx+/wraparound
fx-/wraparound
fx*/wraparound
fxsll/wraparound
fxpopcount
fxpopcount32
fxpopcount16
\endschemedisplay
Immutable fixnum vectors are no longer supported, so the following
functions are removed:
\schemedisplay
fxvector->immutable-fxvector ; removed
mutable-fxvector? ; removed
immutable-fxvector? ; removed
\endschemedisplay
\subsection{New flonum operations (9.9.9)}
The \scheme{eq?} operator works on flonums in the sense that two
flonums values that are \scheme{eq?} at some point (such as creation
time) will continue to be \scheme{eq?} in the future.
Mutable flonum vectors cooperate with local unboxing (see
Section~\ref{sec:unbox-floats}) and are supported through the
following functions:
\schemedisplay
flvector?
make-flvector
flvector-length
flvector-ref
flvector-set!
flvector-fill!
flvector->list
list->flvector
flvector-copy
\endschemedisplay
The \scheme{flsingle} operation drops precision from a flonum so that
the result is representable as a single-precision (32-bit) flonum.
Wrapping each operation of flonum arithmetic with \scheme{flsingle}
produces the same result as single-precision arithmetic, and local
unboxing plus type inference makes the combination reasonably
efficient.
Flonum printing can be controlled by new parameters:
\schemedisplay
print-subnormal-precision
print-positive-exponent-sign
print-select-flonum-exponential-format
\endschemedisplay
The \scheme{fl=}, \scheme{fl<}, , \scheme{fl>}, \scheme{fl<=}, and
\scheme{fl>=} no longer produce \scheme{#f} for a single argument
that's \scheme{+nan.0}, which makes them consistent with \scheme{=},
\scheme{<}, \scheme{>}, \scheme{<=}, and \scheme{>=}.
\subsection{Improved bignum arithmetic (9.9.9)}
Multiplication of very large numbers uses Karatsuba, Toom-3, or
Toom-4, while division (including GCD) uses Burnikel-Ziegler. These
changes make arithmetic and number-to-string conversions faster for
large values, and they avoid unbounded delays between interrupt
polling.
\subsection{Exact zeros, transcendentals, and exponentials (9.9.9)}
Division of an exact \scheme{0} by an inexact number now always
produces exact \scheme{0}, and
division of an inexact number by an exact \scheme{0} now raises an
exception instead of producing \scheme{+inf.0} or \scheme{-inf.0},
This change makes division more consistent with the existing behavior of
multiplication, where multiplication of an inexact number by an exact
\scheme{0} produces an exact \scheme{0}. It should be noted, however, that
this change takes \scheme{/} out of compliance with R6RS.
Small changes to transcendental functions help improve consistency for
derived compositions. The \scheme{expt} function with two
\scheme{+inf.0} or \scheme{-inf.0} arguments now produces
\scheme{+nan.0+nan.0i} instead of a complex number with infinite
components. The \scheme{sqrt} and \scheme{log} functions change so
that \scheme{(sqrt -0.0)} and \scheme{(log -0.0)} produce real
numbers, instead of complex numbers, on the grounds that
\scheme{(negative? -0.0)} produces \scheme{#f}.
The \scheme{expt} function recognizes an exact \scheme{1/2} as its
second argument, and in that case it behaves like \scheme{sqrt}, which
may produce an exact result.
\subsection{New character, string, and Unicode functions (9.9.9)}
New functions support decoding grapheme clusters within strings or
character streams and expose the underlying new character classifiers:
\schemedisplay
string-grapheme-span
string-grapheme-count
char-grapheme-step
char-grapheme-break-property
char-extended-pictographic?
\endschemedisplay
The \scheme{string-append-immutable} function enables the creation of
an immutable string as the result of appending strings without
creating an intermediate mutable string.
The \scheme{path-build} procedure combines two path strings to form a
path, adding a directory separator between them if necessary.
\subsection{Hashtable changes (9.9.9)}
Operations returning hashtable cells (\scheme{hashtable-cell},
\scheme{eq-hashtable-cell}, \scheme{symbol-hashtable-cell}, and
\scheme{hashtable-cells}) now raise an exception when given an immutable
hashtable. This is an \emph{incompatible change}, as they previously
accepted immutable hashtables (and allowed changing them).
The \scheme{make-weak-hashtable} and \scheme{make-ephemeron-hashtable}
functions support weak and ephemeron hash tables with arbitrary
equality and hashing functions.
New operations for hashtable cells resemble procedures like
\scheme{hashtable-keys} or \scheme{hashtable-ref}:
\schemedisplay
hashtable-cells
hashtable-ref-cell
eq-hashtable-ref-cell
symbol-hashtable-ref-cell
\endschemedisplay
The \scheme{eq-hashtable-try-atomic-cell} procedure supports lock-free
use of an \scheme{eq?}-based hash table, but with constraints on
concurrent operations and resizing. Clean-up resizing can be performed
within a collect-request handler, since only one thread can run at that
time.
A weak or ephemeron \scheme{eqv?} hash table now retains non-fixnum
numbers only weakly, instead of strongly. This change is related to
changes to \scheme{eq?} for flonum values and the availability of weak
and ephemeron hash tables with arbitrary equality and hashing
functions.
\subsection{Stencil vectors (9.9.9)}
Stencil vectors provide support in the compiler and runtime for
implementing data structures such as persistent maps:
\schemedisplay
stencil-vector
stencil-vector?
stencil-vector-mask
stencil-vector-length
stencil-vector-ref
stencil-vector-set!
stencil-vector-update
stencil-vector-truncate!
stencil-vector-mask-width
\endschemedisplay
\subsection{New vector functions (9.9.9)}
New and extended (in the case of \scheme{vector-copy}) vector functions
support creating a vector from the content of others:
\schemedisplay
vector-copy
vector-append
vector-set/copy
\endschemedisplay
Although these functions could be implemented with
\scheme{make-vector} and \scheme{vector-set!}, the new versions avoid
redundant initialization and write barriers.
\subsection{New symbol functions (9.9.9)}
While gensyms support most symbol-generation needs, uninterned symbols
are useful for purposes where properties must not prevent a symbol
from being reclaimed by the storage manager:
\schemedisplay
string->uninterned-symbol
uninterned-symbol?
\endschemedisplay
The string returned by \scheme{symbol->string} is always immutable.
\subsection{Record anonymous fields (9.9.9)}
Records can have anonymous fields, which can save memory in the
representation when many record types need to be created (as opposed
to many record instances of a few types), each with many fields. For a
given record type and its ancestors, either all fields are named or
all fields are anonymous.
\schemedisplay
make-record-type-descriptor*
record-type-named-fields?
record-type-field-indices
\endschemedisplay
The new \scheme{record-instance?} predicate is a specialization of
\scheme{record?}, where the first argument is required to be a record.
An unsafe \scheme{record-instance?} test can be faster than an unsafe
\scheme{record?} test.
\subsection{Lists assuming immutability (9.9.9)}
In a context where pairs are not mutated, the new
\scheme{list-assuming-immutable?} predicate is useful as a variant of
the \scheme{list?} predicate. The new predicate implements an
efficient, amortized constant-time decision on whether a value
represents a list, but its behavior is unspecified if the
\scheme{cdr} or any pair relevant to the result is mutated.
\subsection{New random number generation (9.9.9)}
A new random-number API implements the MRG32K3A algorithm:
\schemedisplay
make-pseudo-random-generator
pseudo-random-generator?
pseudo-random-generator-next!
pseudo-random-generator-seed!
pseudo-random-generator->vector
vector->pseudo-random-generator
\endschemedisplay
\subsection{Wrapper procedures (9.9.9)}
A \emph{wrapper procedure} provides an inexpensive way to an adjust a
procedure's name, constrain its arity, or associate extra data to the
procedure. A wrapper procedure is implemented as closure with an
optimized jump to the wrapped procedure after arity checking,
propagating the original arguments faster than \scheme{apply}.
\schemedisplay
make-wrapper-procedure
make-arity-wrapper-procedure
wrapper-procedure?
wrapper-procedure-procedure
wrapper-procedure-data
set-wrapper-procedure-data!
set-wrapper-procedure!
\endschemedisplay
\subsection{New thread functions (9.9.9)}\label{sec:threads}
The new \scheme{thread-join} operator can be used to wait for a thread
to terminate. Waiting for termination in this sense can be useful to
ensure that a single thread is running and calling \scheme{collect} is
legal, for example.
The new \scheme{get-initial-thread} procedure returns a descriptor for
the initial thread (like a descriptor produced by \scheme{fork-thread}
for a subsequently created thread).
The new \scheme{thread-preserve-ownership!} procedure provides a hint
to the storage manager that parallel garbage collection is likely to
benefit by keeping track of which objects were allocated by a given
thread.
Useful on architectures with a weak consistency model,
\scheme{memory-order-acquire} and \scheme{memory-order-release}
implement fencing operators suitable for abstractions that acquire
(load-load and load-store fence) or release (store-store and
store-load fence) shared resources.
When a new thread is created, it now starts with the default
exception-handler stack instead of inheriting the stack of the
creating thread.
\subsection{Garbage collection introspection (9.9.9)}\label{sec:gc-reflect}
Similar to \scheme{enable-object-counts}, the
\scheme{enable-object-backreferences} parameter enables recording of
information about reachability. After a collection with backreferences
enabled, \scheme{object-backreferences} reports an association for
each object to the a referencing object---one that caused the storage
manager to consider the former object reachable.
A new \scheme{bytes-finalized} procedure reports the number of bytes
that have been finalized via guardians, which is useful for deciding
when to perform an extra major collection as a follow-up to an
old-generation garbage collection.
A \emph{phantom bytevector} is a small object that stands for a large
externally allocated object, especially one that can be finalized.
Registering external allocations with the storage manager helps it
trigger collection requests at times that take into account the rate
and scale of external allocation.
\schemedisplay
make-phantom-bytevector
phantom-bytevector?
phantom-bytevector-length
set-phantom-bytevector-length!
\endschemedisplay
The new \scheme{compute-size-increments} procedure is similar to
\scheme{compute-size}. Instead of a single object, it takes a list of
objects, and it reports a list of sizes where any memory use
attributed to objects earlier in the list is not counted for objects
later in the list, while objects later the list are not considered
reachable by objects earlier in the list. For example, given a list of
threads, \scheme{compute-size-increments} effectively treats each
thread as an accounting domain, where memory is charged to an earlier
thread rather than a later thread when objects are reachable from
both. Since this computation involves the same sort of traversal as a
garbage collection, the \scheme{collect} function takes a list as
an optional last argument to fuse a garbage collection with size
accounting.
\subsection{Storage management and foreign interfaces (9.9.9)}\label{sec:ffi-storage}
The \scheme{make-guardian} function accepts an option to create an
\emph{ordered guardian}. An ordered guardian treats each of its
objects as accessible in the case that object is reachable from a
guardian-registered object, whether or not the latter object is
considered accessible. Ordered finalization is error-prone and cannot
handle reference cycles, but it can be necessary to implement certain
storage-management interfaces and abstractions.
An \emph{immobile object} is one that the storage manager will not
relocate as a long as it is referenced, in the same way that a locked
object is never relocated. Unlike a locked object, an immobile
object can be reclaimed by the storage manager.
\schemedisplay
box-immobile
make-immobile-vector
make-immobile-bytevector
\endschemedisplay
For foreign interfaces that involve arrays of references to allocated
objects, the storage manager supports \emph{reference
bytevectors}. A reference bytevector is a bytevector, but each
word-aligned group of bytes is treated as a potential reference to an
object managed by the collector; only a word whose value corresponds a
region of managed memory is treated as an object reference, and it can
be updated by the garbage collector if the referenced object is
relocated. Using the reference-bytevector interface requires care, but
it can greatly simplify certain foreign-library interactions. An
object reference in a bytevector takes the form of a \emph{reference
address} for a Scheme object. The reference address of a bytevector
(including a reference bytevector) or flvector is the address of the
first byte of its content.
\schemedisplay
make-reference-bytevector
make-immobile-reference-bytevector
reference-bytevector?
bytevector-reference-set!
bytevector-reference-ref
bytevector-reference*-ref
object->reference-address
reference-address->object
reference*-address->object
\endschemedisplay
The \scheme{keep-live} procedure accepts any value and returns
\scheme{(void)}, but the argument to \scheme{keep-live} is defined to
be reachable until the call to \scheme{keep-live} returns.
The maximum non-static generation for collection has been reduced from
254 to 6. This change is related to parallel garbage collection and
internal changes that make allocation thread-local, which in turn
makes the size of a thread's representation proportional to the
maximum number of generations.
\subsection{Foreign interface extensions (9.9.9)}
Some ABIs treat functions with varargs (i.e., specified with
\scheme{...} in the C prototype) differently than functions without
varargs, and some ABIs treat specific arguments differently depending
on whether the argument is a vararg (i.e., before the \scheme{...} or
not). A procedure type described with \scheme{foreign-procedure} or a
\scheme{function} type can include a \scheme{__varargs} or
\scheme{(__varargs_after \var{n})} convention to indicate which
arguments of a function are varargs.
The new \scheme{foreign-alignof} procedure reflects alignment
information for a primitive type.
To better support the pb machine type, where endianness is not known
statically, endianness in a foreign type can not be \scheme{native} or
\scheme{swapped} in addition to \scheme{big} or \scheme{little}.
Chez Scheme's kernel also expose record-type and field access to
C, mainly useful for for records that contain only pointer-sized
values:
\schemedisplay
Srecord_type
Srecord_type_parent
Srecord_type_size
Srecord_type_uniformp
Srecord_uniform_ref
\endschemedisplay
The kernel also provides a new function
\scheme{Sregister_boot_file_fd_segment} for loading a boot file from a
file descriptor and offset. This form of boot-file registration is
useful for loading boot files that are embedded with an executable
segment.
\subsection{Fasl and vfasl (9.9.9)}
Reading fasl data has been made safe no matter how deeply nested the
structure of the data.
For reading and writing fasl data, the \scheme{fasl-write} procedure
accepts a predicate to detect ``external'' values for which only a
placeholder is saved, and \scheme{fasl-read} accepts a table of
external values to substitute for placeholders. These ``external''
values can then have their own serialization and deserialization. The
\scheme{fasl-write} function also accepts an option to save a record
type as only its unique ID, which can save space and time in contexts
where the relevant record types will always be available already (and
where savings are worth skipping a consistency check). The
\scheme{compile-to-port} procedure accepts new arguments like
\scheme{fasl-write}.
A fasl stream can be converted a \emph{vfasl} (very fasl) format,
which is close in structure to an image of data in memory. Using vfasl
for boot files to load directly into a static generation can make
startup much faster; otherwise, the time--space tradeoff rarely pays
off. Convert from fasl to vfasl using \scheme{vfasl-convert-file}.
\subsection{New compiler options (9.9.9)}
Two new parameters skip safety checks in specific situations:
\scheme{enable-unsafe-application} assumes that the target of a
procedure application is a procedure, and
\scheme{enable-unsafe-variable-reference} assumes that a variable has
a value when it is referenced. These checks would be skipped at
\scheme{optimize-level} 3, but the parameters cause them to be skipped
independent of the value of \scheme{optimize-level}.
A true value for the \scheme{enable-arithmetic-left-associative}
parameter ensures that arithmetic operations are performed as
left-associative, which amounts to a constraint on optimizations.
A new set of parameters control the way that libraries are compiled
and invoked so that consistency checks, invocations checks, and
recompilations can be skipped (to save time and space) in a context
that ensures that they are unnecessary:
\schemedisplay
library-timestamp-mode
expand-omit-library-invocations
compile-omit-concatenate-support
\endschemedisplay
Along those lines, the \scheme{current-generate-id} parameter provides
control over names that are generated during macro expansion. While
the default parameter uses \scheme{gensym}, name generation can
potentially be made deterministic, which in turn may reduce the need
to recompile clients.
The new \scheme{procedure-known-single-valued?} predicate is always
allowed to return \scheme{#f}, but it may return \scheme{#t} for a
procedure that the compiler was able to prove always returns a single
value. This information may, in turn, be useful for run-time
specialization in a library.
Procedure objects recognize the \scheme{realm} inspector message
alongside \scheme{name}. The result for \scheme{realm} is normally
\scheme{#f}, but if \scheme{compile-procedure-realm} is set to a
symbol when the procedure is compiled, then the procedure answers
\scheme{realm} with that symbol. The intent of a realm is that it
describes where a procedure name came from, so the name can be
converted as appropriate for a run-time context that uses different
naming conventions.
The \scheme{enable-error-source-expression} parameter determines
whether error messages that become embedded in code can refer to the
original source file's path.
\subsection{Executable-relative boot files (9.9.9)}
When searching for boot files, the two-character escape sequence
``\scheme{%x}'' is now supported on more platforms. By default, Chez
Scheme is configured to use this facility to find boot files relative
to the executable, even when installed.
\subsection{Syntax quoting (9.9.9)}
The new \scheme{quote-syntax} form is like the R$^6$RS \scheme{syntax}
form except that pattern variables are not substituted. It can be
useful for macro transformers that need to embed syntax objects based
on the input in the output.
\subsection{New conversions from Scheme to C signed and unsigned integers (9.6.4)}
The following new functions
allow foreign code to try converting Scheme
values to signed or unsigned integer values
without triggering a \scheme{longjmp} in the Scheme runtime
as can happen when calling the corresponding functions
\scheme{Sinteger_value}, etc:
\schemedisplay
Stry_integer_value
Stry_integer32_value
Stry_integer64_value
Stry_unsigned_value
Stry_unsigned32_value
Stry_unsigned64_value
\endschemedisplay
\subsection{New types for code that uses C exports (9.6.4)}
The header file scheme.h distributed with Chez Scheme now defines
\scheme{Sint32_t}, \scheme{Suint32_t}, \scheme{Sint64_t}, and \scheme{Suint64_t}
types for 32-bit and 64-bit signed and unsigned integers that are compatible
with the types for exports such as \scheme{Sinteger64}.
\subsection{New transcoded port buffer-size parameters (9.6.0)}
The new parameter \scheme{transcoded-port-buffer-size} specifies the size
of the string buffer that is allocated when creating a new transcoded port.
If the underlying binary port implements \scheme{port-position},
a transcoded input port allocates an internal fxvector the same size
as its string buffer for use by \scheme{port-position}.
The new parameter \scheme{make-codec-buffer} can be used to supply an appropriately
sized internal bytevector buffer for the codec used by a new transcoded port.
The size of these string and bytevector buffers was previously hardcoded at 1024.
\subsection{Unicode 15.0 support (9.6.0)}
The character sets, character classes, and word-breaking algorithms for character, string,
and Unicode-related bytevector operations have now been updated to Unicode 15.0.
\subsection{Basic ftypes can be referenced, even if shadowed by syntactic binding (9.5.8)}
Previously, it was possible to interfere with the definition of ftypes by
creating a syntactic binding for one of the built-in types, such as
\scheme{integer-32}, \scheme{float}, etc.
As of 9.5.8, syntactic bindings that do not bind an ftype descriptor are no
longer considered when defining ftypes.
This change also allows a base ftype to be bound using \scheme{define-ftype}, though
this fixes the endianness of the type. For instance:
\schemedisplay
(define-ftype integer-32 integer-32)
\endschemedisplay
This binds the ftype \scheme{integer-32} to the native-endian \scheme{integer-32}. It is possible to bind both endiannesses by using explicit names:
\schemedisplay
(define-ftype integer-32-be (endian big integer-32))
(define-ftype integer-32-le (endian little integer-32))
(define-ftype integer-32 integer-32) ;; fixed to native endianness
\endschemedisplay
\subsection{Improved error messages (9.5.6)}
When the reader reports an invalid bytevector element, the error
message now includes the token value only if the token type is atomic.
When the expander reports that an ellipsis is missing in a syntax form,
it now includes the name of an identifier that is missing an ellipsis
within that form.
\subsection{Additional reader syntax for booleans (9.5.6)}
The reader now case-insensitively accepts \scheme{#true} and
\scheme{#false} as alternative spellings of the booleans \scheme{#t}
and \scheme{#f}, respectively.
\subsection{Self-evaluating vector literals (9.5.6)}
The new parameter \scheme{self-evaluating-vectors} can be used to treat unquoted vector
literals as self-evaluating instead of syntax errors. This parameter is turned off by
default.
\subsection{Incremental promotion of collected objects (9.5.4)}
In previous versions of {\ChezScheme}, the collector always promoted
surviving objects from every collected generation into a single
target generation.
For example, when the target generation was 3, it promoted not only
surviving objects from generation 2 to generation 3 but also surviving
objects from generations 0 and 1 directly to generation 3.
This caused some prematurely promoted objects to be subjected to
collection less frequently than their ages justified, potentially
resulting in substantial inappropriate storage retention.
This is particularly problematic when side effects result in pointers
from the inappropriately retained objects to younger objects, as
can happen with nonfunctional queues and lazy streams.
Unless directed to do otherwise, the collector now promotes objects
up only one generation at a time.
That is, generation 0 objects that survive collection are promoted
to generation 1, generation 1 objects are promoted to generation
2, and so on.
(Objects that survive a maximum nonstatic collection are promoted
back into the maximum nonstatic collection.)
Most applications should exhibit lower peak memory usage and possibly
lower run times with this change.
Applications that are adversely affected, if any, might benefit
from a custom collect-request handler or custom values for the
collection parameters that affect the behavior of the default
handler.
\subsection{Unicode Basic Multilingual Plane console I/O in Windows (9.5.4)}
Console I/O now supports characters from the Unicode Basic
Multilingual Plane in Windows. Windows consoles do not yet support the
supplementary planes.
\subsection{Incompatible fasl-format and compiled-file compression changes (9.5.4)}
The fasl (fast-load) format now supports per-object compression.
Whether the fasl writer actually performs compression is determined
by the new \scheme{fasl-compressed} parameter, whose value defaults
to \scheme{#t}.
The compression format and level are determined by the
\scheme{compress-format} and \scheme{compress-level}
parameters.
The \scheme{compile-compressed} parameter has been eliminated.
Since compiled files are written in fasl format, the
\scheme{fasl-compressed} parameter also now controls whether compiled
files are compressed.
Because individual portions of a fasl file are already compressed
by default, attempting to compress a fasl file as a whole is often
ineffective as well as inefficient both when writing and reading
fasl objects.
Thus, in particular, the \var{output-port} and \scheme{wpo-port}
supplied to \scheme{compile-port} and \scheme{compile-to-port}
should not be opened for compression.
Similarly, external tools should not expect compiled files to be
compressed as a whole, nor should they compress compiled files.
Because compression of fasl files was previously encouraged and is
now discouraged, the first attempt to write fasl data to or read
fasl data from a compressed port will cause a warning to be issued,
i.e., an exception with condition type \scheme{&warning} to be
raised.
The rationale for this change is to allow the fasl reader to seek
past, without reading, portions of an object file that contain
compile-time code at run time and run-time code at compile time.
\subsection{Bytevector compression and compression level (9.5.4)}
The procedure \scheme{bytevector-compress} now selects the level of
compression based on the \scheme{compress-level} parameter.
Prior to this it always used a default setting for compression.
The \scheme{compress-level} parameter can now take on the new value
\scheme{minimum} in addition to \scheme{low}, \scheme{medium},
\scheme{high}, and \scheme{maximum}.
\subsection{Combining object files (9.5.4)}
In previous versions of Chez Scheme, multiple object files could
be combined by concatenating them into a single file. To support faster
object file loading and loadability verification (described later in this
document), recompile information and information about libraries and
top-level programs within an object file is now placed at the top of the
file. The new \scheme{concatenate-object-files} procedure can be used to
combine multiple object files while moving this information to the
top of the combined file.
\subsection{Explicitly invoking libraries (9.5.4)}
The new procedure \scheme{invoke-library} can be used to force
the evaluation of a library's body expressions (variable definition
right-hand sides and initialization expressions) before they might
otherwise be needed.
It is generally useful only for libraries whose body expressions
have side effects.
\subsection{Verifying loadability of libraries and programs (9.5.4)}
The new procedure \scheme{verify-loadability} can be used to
determine, without actually loading any object code or defining any
libraries, whether a set of object files and the object files
satisfying their library dependencies, direct or indirect, are
present, readable, and mutually compatible.