Commit | Line | Data |
---|---|---|
2da09c3f MV |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Guile Reference Manual. | |
3 | @c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004 | |
4 | @c Free Software Foundation, Inc. | |
5 | @c See the file guile.texi for copying conditions. | |
6 | ||
a0e07ba4 NJ |
7 | @page |
8 | @node SRFI Support | |
3229f68b | 9 | @section SRFI Support Modules |
8742c48b | 10 | @cindex SRFI |
a0e07ba4 NJ |
11 | |
12 | SRFI is an acronym for Scheme Request For Implementation. The SRFI | |
13 | documents define a lot of syntactic and procedure extensions to standard | |
14 | Scheme as defined in R5RS. | |
15 | ||
16 | Guile has support for a number of SRFIs. This chapter gives an overview | |
17 | over the available SRFIs and some usage hints. For complete | |
18 | documentation, design rationales and further examples, we advise you to | |
19 | get the relevant SRFI documents from the SRFI home page | |
20 | @url{http://srfi.schemers.org}. | |
21 | ||
22 | @menu | |
23 | * About SRFI Usage:: What to know about Guile's SRFI support. | |
24 | * SRFI-0:: cond-expand | |
25 | * SRFI-1:: List library. | |
26 | * SRFI-2:: and-let*. | |
27 | * SRFI-4:: Homogeneous numeric vector datatypes. | |
28 | * SRFI-6:: Basic String Ports. | |
29 | * SRFI-8:: receive. | |
30 | * SRFI-9:: define-record-type. | |
31 | * SRFI-10:: Hash-Comma Reader Extension. | |
32 | * SRFI-11:: let-values and let-values*. | |
33 | * SRFI-13:: String library. | |
34 | * SRFI-14:: Character-set library. | |
35 | * SRFI-16:: case-lambda | |
36 | * SRFI-17:: Generalized set! | |
bfc9c8e0 | 37 | * SRFI-19:: Time/Date library. |
1de8c1ae | 38 | * SRFI-26:: Specializing parameters |
8638c417 | 39 | * SRFI-31:: A special form `rec' for recursive evaluation |
eeadfda1 | 40 | * SRFI-39:: Parameter objects |
4ea9becb | 41 | * SRFI-55:: Requiring Features. |
8503beb8 | 42 | * SRFI-60:: Integers as bits. |
43ed3b69 | 43 | * SRFI-61:: A more general `cond' clause |
a0e07ba4 NJ |
44 | @end menu |
45 | ||
46 | ||
47 | @node About SRFI Usage | |
3229f68b | 48 | @subsection About SRFI Usage |
a0e07ba4 NJ |
49 | |
50 | @c FIXME::martin: Review me! | |
51 | ||
52 | SRFI support in Guile is currently implemented partly in the core | |
53 | library, and partly as add-on modules. That means that some SRFIs are | |
54 | automatically available when the interpreter is started, whereas the | |
55 | other SRFIs require you to use the appropriate support module | |
12991fed | 56 | explicitly. |
a0e07ba4 NJ |
57 | |
58 | There are several reasons for this inconsistency. First, the feature | |
59 | checking syntactic form @code{cond-expand} (@pxref{SRFI-0}) must be | |
60 | available immediately, because it must be there when the user wants to | |
61 | check for the Scheme implementation, that is, before she can know that | |
62 | it is safe to use @code{use-modules} to load SRFI support modules. The | |
63 | second reason is that some features defined in SRFIs had been | |
64 | implemented in Guile before the developers started to add SRFI | |
65 | implementations as modules (for example SRFI-6 (@pxref{SRFI-6})). In | |
66 | the future, it is possible that SRFIs in the core library might be | |
67 | factored out into separate modules, requiring explicit module loading | |
68 | when they are needed. So you should be prepared to have to use | |
69 | @code{use-modules} someday in the future to access SRFI-6 bindings. If | |
70 | you want, you can do that already. We have included the module | |
71 | @code{(srfi srfi-6)} in the distribution, which currently does nothing, | |
72 | but ensures that you can write future-safe code. | |
73 | ||
74 | Generally, support for a specific SRFI is made available by using | |
75 | modules named @code{(srfi srfi-@var{number})}, where @var{number} is the | |
76 | number of the SRFI needed. Another possibility is to use the command | |
77 | line option @code{--use-srfi}, which will load the necessary modules | |
78 | automatically (@pxref{Invoking Guile}). | |
79 | ||
80 | ||
81 | @node SRFI-0 | |
3229f68b | 82 | @subsection SRFI-0 - cond-expand |
8742c48b | 83 | @cindex SRFI-0 |
a0e07ba4 | 84 | |
5eef0f61 KR |
85 | This SRFI lets a portable Scheme program test for the presence of |
86 | certain features, and adapt itself by using different blocks of code, | |
87 | or fail if the necessary features are not available. There's no | |
88 | module to load, this is in the Guile core. | |
a0e07ba4 | 89 | |
5eef0f61 KR |
90 | A program designed only for Guile will generally not need this |
91 | mechanism, such a program can of course directly use the various | |
92 | documented parts of Guile. | |
a0e07ba4 | 93 | |
5eef0f61 KR |
94 | @deffn syntax cond-expand (feature body@dots{}) @dots{} |
95 | Expand to the @var{body} of the first clause whose @var{feature} | |
96 | specification is satisfied. It is an error if no @var{feature} is | |
a0e07ba4 NJ |
97 | satisfied. |
98 | ||
5eef0f61 KR |
99 | Features are symbols such as @code{srfi-1}, and a feature |
100 | specification can use @code{and}, @code{or} and @code{not} forms to | |
101 | test combinations. The last clause can be an @code{else}, to be used | |
102 | if no other passes. | |
a0e07ba4 | 103 | |
5eef0f61 KR |
104 | For example, define a private version of @code{alist-cons} if SRFI-1 |
105 | is not available. | |
a0e07ba4 | 106 | |
5eef0f61 KR |
107 | @example |
108 | (cond-expand (srfi-1 | |
109 | ) | |
110 | (else | |
111 | (define (alist-cons key val alist) | |
112 | (cons (cons key val) alist)))) | |
113 | @end example | |
a0e07ba4 | 114 | |
5eef0f61 KR |
115 | Or demand a certain set of SRFIs (list operations, string ports, |
116 | @code{receive} and string operations), failing if they're not | |
117 | available. | |
a0e07ba4 | 118 | |
5eef0f61 KR |
119 | @example |
120 | (cond-expand ((and srfi-1 srfi-6 srfi-8 srfi-13) | |
121 | )) | |
122 | @end example | |
123 | @end deffn | |
a0e07ba4 | 124 | |
f38d22c5 KR |
125 | @noindent |
126 | The Guile core has the following features, | |
127 | ||
128 | @example | |
129 | guile | |
130 | r5rs | |
131 | srfi-0 | |
132 | srfi-4 | |
133 | srfi-6 | |
134 | srfi-13 | |
135 | srfi-14 | |
136 | @end example | |
137 | ||
138 | Other SRFI feature symbols are defined once their code has been loaded | |
139 | with @code{use-modules}, since only then are their bindings available. | |
a0e07ba4 | 140 | |
5eef0f61 KR |
141 | The @samp{--use-srfi} command line option (@pxref{Invoking Guile}) is |
142 | a good way to load SRFIs to satisfy @code{cond-expand} when running a | |
143 | portable program. | |
a0e07ba4 | 144 | |
5eef0f61 KR |
145 | Testing the @code{guile} feature allows a program to adapt itself to |
146 | the Guile module system, but still run on other Scheme systems. For | |
147 | example the following demands SRFI-8 (@code{receive}), but also knows | |
148 | how to load it with the Guile mechanism. | |
a0e07ba4 NJ |
149 | |
150 | @example | |
5eef0f61 KR |
151 | (cond-expand (srfi-8 |
152 | ) | |
153 | (guile | |
154 | (use-modules (srfi srfi-8)))) | |
a0e07ba4 NJ |
155 | @end example |
156 | ||
5eef0f61 KR |
157 | It should be noted that @code{cond-expand} is separate from the |
158 | @code{*features*} mechanism (@pxref{Feature Tracking}), feature | |
159 | symbols in one are unrelated to those in the other. | |
a0e07ba4 NJ |
160 | |
161 | ||
162 | @node SRFI-1 | |
3229f68b | 163 | @subsection SRFI-1 - List library |
8742c48b | 164 | @cindex SRFI-1 |
7c2e18cd | 165 | @cindex list |
a0e07ba4 NJ |
166 | |
167 | @c FIXME::martin: Review me! | |
168 | ||
169 | The list library defined in SRFI-1 contains a lot of useful list | |
170 | processing procedures for construction, examining, destructuring and | |
171 | manipulating lists and pairs. | |
172 | ||
173 | Since SRFI-1 also defines some procedures which are already contained | |
174 | in R5RS and thus are supported by the Guile core library, some list | |
175 | and pair procedures which appear in the SRFI-1 document may not appear | |
176 | in this section. So when looking for a particular list/pair | |
177 | processing procedure, you should also have a look at the sections | |
178 | @ref{Lists} and @ref{Pairs}. | |
179 | ||
180 | @menu | |
181 | * SRFI-1 Constructors:: Constructing new lists. | |
182 | * SRFI-1 Predicates:: Testing list for specific properties. | |
183 | * SRFI-1 Selectors:: Selecting elements from lists. | |
184 | * SRFI-1 Length Append etc:: Length calculation and list appending. | |
185 | * SRFI-1 Fold and Map:: Higher-order list processing. | |
186 | * SRFI-1 Filtering and Partitioning:: Filter lists based on predicates. | |
85a9b4ed | 187 | * SRFI-1 Searching:: Search for elements. |
a0e07ba4 NJ |
188 | * SRFI-1 Deleting:: Delete elements from lists. |
189 | * SRFI-1 Association Lists:: Handle association lists. | |
190 | * SRFI-1 Set Operations:: Use lists for representing sets. | |
191 | @end menu | |
192 | ||
193 | @node SRFI-1 Constructors | |
3229f68b | 194 | @subsubsection Constructors |
7c2e18cd | 195 | @cindex list constructor |
a0e07ba4 NJ |
196 | |
197 | @c FIXME::martin: Review me! | |
198 | ||
199 | New lists can be constructed by calling one of the following | |
200 | procedures. | |
201 | ||
8f85c0c6 | 202 | @deffn {Scheme Procedure} xcons d a |
a0e07ba4 NJ |
203 | Like @code{cons}, but with interchanged arguments. Useful mostly when |
204 | passed to higher-order procedures. | |
205 | @end deffn | |
206 | ||
8f85c0c6 | 207 | @deffn {Scheme Procedure} list-tabulate n init-proc |
a0e07ba4 NJ |
208 | Return an @var{n}-element list, where each list element is produced by |
209 | applying the procedure @var{init-proc} to the corresponding list | |
210 | index. The order in which @var{init-proc} is applied to the indices | |
211 | is not specified. | |
212 | @end deffn | |
213 | ||
57066448 KR |
214 | @deffn {Scheme Procedure} list-copy lst |
215 | Return a new list containing the elements of the list @var{lst}. | |
216 | ||
217 | This function differs from the core @code{list-copy} (@pxref{List | |
218 | Constructors}) in accepting improper lists too. And if @var{lst} is | |
219 | not a pair at all then it's treated as the final tail of an improper | |
220 | list and simply returned. | |
221 | @end deffn | |
222 | ||
8f85c0c6 | 223 | @deffn {Scheme Procedure} circular-list elt1 elt2 @dots{} |
a0e07ba4 NJ |
224 | Return a circular list containing the given arguments @var{elt1} |
225 | @var{elt2} @dots{}. | |
226 | @end deffn | |
227 | ||
8f85c0c6 | 228 | @deffn {Scheme Procedure} iota count [start step] |
256853db KR |
229 | Return a list containing @var{count} numbers, starting from |
230 | @var{start} and adding @var{step} each time. The default @var{start} | |
231 | is 0, the default @var{step} is 1. For example, | |
a0e07ba4 | 232 | |
256853db KR |
233 | @example |
234 | (iota 6) @result{} (0 1 2 3 4 5) | |
235 | (iota 4 2.5 -2) @result{} (2.5 0.5 -1.5 -3.5) | |
236 | @end example | |
a0e07ba4 | 237 | |
256853db KR |
238 | This function takes its name from the corresponding primitive in the |
239 | APL language. | |
a0e07ba4 NJ |
240 | @end deffn |
241 | ||
242 | ||
243 | @node SRFI-1 Predicates | |
3229f68b | 244 | @subsubsection Predicates |
7c2e18cd | 245 | @cindex list predicate |
a0e07ba4 NJ |
246 | |
247 | @c FIXME::martin: Review me! | |
248 | ||
249 | The procedures in this section test specific properties of lists. | |
250 | ||
8f85c0c6 | 251 | @deffn {Scheme Procedure} proper-list? obj |
f18f87aa KR |
252 | Return @code{#t} if @var{obj} is a proper list, or @code{#f} |
253 | otherwise. This is the same as the core @code{list?} (@pxref{List | |
254 | Predicates}). | |
255 | ||
256 | A proper list is a list which ends with the empty list @code{()} in | |
257 | the usual way. The empty list @code{()} itself is a proper list too. | |
258 | ||
259 | @example | |
260 | (proper-list? '(1 2 3)) @result{} #t | |
261 | (proper-list? '()) @result{} #t | |
262 | @end example | |
a0e07ba4 NJ |
263 | @end deffn |
264 | ||
8f85c0c6 | 265 | @deffn {Scheme Procedure} circular-list? obj |
f18f87aa KR |
266 | Return @code{#t} if @var{obj} is a circular list, or @code{#f} |
267 | otherwise. | |
268 | ||
269 | A circular list is a list where at some point the @code{cdr} refers | |
270 | back to a previous pair in the list (either the start or some later | |
271 | point), so that following the @code{cdr}s takes you around in a | |
272 | circle, with no end. | |
273 | ||
274 | @example | |
275 | (define x (list 1 2 3 4)) | |
276 | (set-cdr! (last-pair x) (cddr x)) | |
277 | x @result{} (1 2 3 4 3 4 3 4 ...) | |
278 | (circular-list? x) @result{} #t | |
279 | @end example | |
a0e07ba4 NJ |
280 | @end deffn |
281 | ||
8f85c0c6 | 282 | @deffn {Scheme Procedure} dotted-list? obj |
f18f87aa KR |
283 | Return @code{#t} if @var{obj} is a dotted list, or @code{#f} |
284 | otherwise. | |
285 | ||
286 | A dotted list is a list where the @code{cdr} of the last pair is not | |
287 | the empty list @code{()}. Any non-pair @var{obj} is also considered a | |
288 | dotted list, with length zero. | |
289 | ||
290 | @example | |
291 | (dotted-list? '(1 2 . 3)) @result{} #t | |
292 | (dotted-list? 99) @result{} #t | |
293 | @end example | |
a0e07ba4 NJ |
294 | @end deffn |
295 | ||
f18f87aa KR |
296 | It will be noted that any Scheme object passes exactly one of the |
297 | above three tests @code{proper-list?}, @code{circular-list?} and | |
298 | @code{dotted-list?}. Non-lists are @code{dotted-list?}, finite lists | |
299 | are either @code{proper-list?} or @code{dotted-list?}, and infinite | |
300 | lists are @code{circular-list?}. | |
301 | ||
302 | @sp 1 | |
8f85c0c6 | 303 | @deffn {Scheme Procedure} null-list? lst |
a0e07ba4 NJ |
304 | Return @code{#t} if @var{lst} is the empty list @code{()}, @code{#f} |
305 | otherwise. If something else than a proper or circular list is passed | |
85a9b4ed | 306 | as @var{lst}, an error is signalled. This procedure is recommended |
a0e07ba4 NJ |
307 | for checking for the end of a list in contexts where dotted lists are |
308 | not allowed. | |
309 | @end deffn | |
310 | ||
8f85c0c6 | 311 | @deffn {Scheme Procedure} not-pair? obj |
a0e07ba4 NJ |
312 | Return @code{#t} is @var{obj} is not a pair, @code{#f} otherwise. |
313 | This is shorthand notation @code{(not (pair? @var{obj}))} and is | |
314 | supposed to be used for end-of-list checking in contexts where dotted | |
315 | lists are allowed. | |
316 | @end deffn | |
317 | ||
8f85c0c6 | 318 | @deffn {Scheme Procedure} list= elt= list1 @dots{} |
a0e07ba4 NJ |
319 | Return @code{#t} if all argument lists are equal, @code{#f} otherwise. |
320 | List equality is determined by testing whether all lists have the same | |
321 | length and the corresponding elements are equal in the sense of the | |
322 | equality predicate @var{elt=}. If no or only one list is given, | |
323 | @code{#t} is returned. | |
324 | @end deffn | |
325 | ||
326 | ||
327 | @node SRFI-1 Selectors | |
3229f68b | 328 | @subsubsection Selectors |
7c2e18cd | 329 | @cindex list selector |
a0e07ba4 NJ |
330 | |
331 | @c FIXME::martin: Review me! | |
332 | ||
8f85c0c6 NJ |
333 | @deffn {Scheme Procedure} first pair |
334 | @deffnx {Scheme Procedure} second pair | |
335 | @deffnx {Scheme Procedure} third pair | |
336 | @deffnx {Scheme Procedure} fourth pair | |
337 | @deffnx {Scheme Procedure} fifth pair | |
338 | @deffnx {Scheme Procedure} sixth pair | |
339 | @deffnx {Scheme Procedure} seventh pair | |
340 | @deffnx {Scheme Procedure} eighth pair | |
341 | @deffnx {Scheme Procedure} ninth pair | |
342 | @deffnx {Scheme Procedure} tenth pair | |
a0e07ba4 NJ |
343 | These are synonyms for @code{car}, @code{cadr}, @code{caddr}, @dots{}. |
344 | @end deffn | |
345 | ||
8f85c0c6 | 346 | @deffn {Scheme Procedure} car+cdr pair |
a0e07ba4 NJ |
347 | Return two values, the @sc{car} and the @sc{cdr} of @var{pair}. |
348 | @end deffn | |
349 | ||
8f85c0c6 NJ |
350 | @deffn {Scheme Procedure} take lst i |
351 | @deffnx {Scheme Procedure} take! lst i | |
a0e07ba4 NJ |
352 | Return a list containing the first @var{i} elements of @var{lst}. |
353 | ||
354 | @code{take!} may modify the structure of the argument list @var{lst} | |
355 | in order to produce the result. | |
356 | @end deffn | |
357 | ||
8f85c0c6 | 358 | @deffn {Scheme Procedure} drop lst i |
a0e07ba4 NJ |
359 | Return a list containing all but the first @var{i} elements of |
360 | @var{lst}. | |
361 | @end deffn | |
362 | ||
8f85c0c6 | 363 | @deffn {Scheme Procedure} take-right lst i |
a0e07ba4 | 364 | Return the a list containing the @var{i} last elements of @var{lst}. |
64bf8517 | 365 | The return shares a common tail with @var{lst}. |
a0e07ba4 NJ |
366 | @end deffn |
367 | ||
8f85c0c6 NJ |
368 | @deffn {Scheme Procedure} drop-right lst i |
369 | @deffnx {Scheme Procedure} drop-right! lst i | |
a0e07ba4 NJ |
370 | Return the a list containing all but the @var{i} last elements of |
371 | @var{lst}. | |
372 | ||
64bf8517 KR |
373 | @code{drop-right} always returns a new list, even when @var{i} is |
374 | zero. @code{drop-right!} may modify the structure of the argument | |
375 | list @var{lst} in order to produce the result. | |
a0e07ba4 NJ |
376 | @end deffn |
377 | ||
8f85c0c6 NJ |
378 | @deffn {Scheme Procedure} split-at lst i |
379 | @deffnx {Scheme Procedure} split-at! lst i | |
a0e07ba4 NJ |
380 | Return two values, a list containing the first @var{i} elements of the |
381 | list @var{lst} and a list containing the remaining elements. | |
382 | ||
383 | @code{split-at!} may modify the structure of the argument list | |
384 | @var{lst} in order to produce the result. | |
385 | @end deffn | |
386 | ||
8f85c0c6 | 387 | @deffn {Scheme Procedure} last lst |
a0e07ba4 NJ |
388 | Return the last element of the non-empty, finite list @var{lst}. |
389 | @end deffn | |
390 | ||
391 | ||
392 | @node SRFI-1 Length Append etc | |
3229f68b | 393 | @subsubsection Length, Append, Concatenate, etc. |
a0e07ba4 NJ |
394 | |
395 | @c FIXME::martin: Review me! | |
396 | ||
8f85c0c6 | 397 | @deffn {Scheme Procedure} length+ lst |
a0e07ba4 NJ |
398 | Return the length of the argument list @var{lst}. When @var{lst} is a |
399 | circular list, @code{#f} is returned. | |
400 | @end deffn | |
401 | ||
8f85c0c6 NJ |
402 | @deffn {Scheme Procedure} concatenate list-of-lists |
403 | @deffnx {Scheme Procedure} concatenate! list-of-lists | |
a0e07ba4 NJ |
404 | Construct a list by appending all lists in @var{list-of-lists}. |
405 | ||
406 | @code{concatenate!} may modify the structure of the given lists in | |
407 | order to produce the result. | |
a3e856f2 KR |
408 | |
409 | @code{concatenate} is the same as @code{(apply append | |
410 | @var{list-of-lists})}. It exists because some Scheme implementations | |
411 | have a limit on the number of arguments a function takes, which the | |
412 | @code{apply} might exceed. In Guile there is no such limit. | |
a0e07ba4 NJ |
413 | @end deffn |
414 | ||
8f85c0c6 NJ |
415 | @deffn {Scheme Procedure} append-reverse rev-head tail |
416 | @deffnx {Scheme Procedure} append-reverse! rev-head tail | |
a0e07ba4 NJ |
417 | Reverse @var{rev-head}, append @var{tail} and return the result. This |
418 | is equivalent to @code{(append (reverse @var{rev-head}) @var{tail})}, | |
419 | but more efficient. | |
420 | ||
421 | @code{append-reverse!} may modify @var{rev-head} in order to produce | |
422 | the result. | |
423 | @end deffn | |
424 | ||
8f85c0c6 | 425 | @deffn {Scheme Procedure} zip lst1 lst2 @dots{} |
a0e07ba4 NJ |
426 | Return a list as long as the shortest of the argument lists, where |
427 | each element is a list. The first list contains the first elements of | |
428 | the argument lists, the second list contains the second elements, and | |
429 | so on. | |
430 | @end deffn | |
431 | ||
8f85c0c6 NJ |
432 | @deffn {Scheme Procedure} unzip1 lst |
433 | @deffnx {Scheme Procedure} unzip2 lst | |
434 | @deffnx {Scheme Procedure} unzip3 lst | |
435 | @deffnx {Scheme Procedure} unzip4 lst | |
436 | @deffnx {Scheme Procedure} unzip5 lst | |
a0e07ba4 NJ |
437 | @code{unzip1} takes a list of lists, and returns a list containing the |
438 | first elements of each list, @code{unzip2} returns two lists, the | |
439 | first containing the first elements of each lists and the second | |
440 | containing the second elements of each lists, and so on. | |
441 | @end deffn | |
442 | ||
e508c863 KR |
443 | @deffn {Scheme Procedure} count pred lst1 @dots{} lstN |
444 | Return a count of the number of times @var{pred} returns true when | |
445 | called on elements from the given lists. | |
446 | ||
447 | @var{pred} is called with @var{N} parameters @code{(@var{pred} | |
448 | @var{elem1} @dots{} @var{elemN})}, each element being from the | |
449 | corresponding @var{lst1} @dots{} @var{lstN}. The first call is with | |
450 | the first element of each list, the second with the second element | |
451 | from each, and so on. | |
452 | ||
453 | Counting stops when the end of the shortest list is reached. At least | |
454 | one list must be non-circular. | |
455 | @end deffn | |
456 | ||
a0e07ba4 NJ |
457 | |
458 | @node SRFI-1 Fold and Map | |
3229f68b | 459 | @subsubsection Fold, Unfold & Map |
7c2e18cd KR |
460 | @cindex list fold |
461 | @cindex list map | |
a0e07ba4 NJ |
462 | |
463 | @c FIXME::martin: Review me! | |
464 | ||
1e181a08 KR |
465 | @deffn {Scheme Procedure} fold proc init lst1 @dots{} lstN |
466 | @deffnx {Scheme Procedure} fold-right proc init lst1 @dots{} lstN | |
467 | Apply @var{proc} to the elements of @var{lst1} @dots{} @var{lstN} to | |
468 | build a result, and return that result. | |
a0e07ba4 | 469 | |
1e181a08 KR |
470 | Each @var{proc} call is @code{(@var{proc} @var{elem1} @dots{} |
471 | @var{elemN} @var{previous})}, where @var{elem1} is from @var{lst1}, | |
472 | through @var{elemN} from @var{lstN}. @var{previous} is the return | |
473 | from the previous call to @var{proc}, or the given @var{init} for the | |
474 | first call. If any list is empty, just @var{init} is returned. | |
a0e07ba4 | 475 | |
1e181a08 KR |
476 | @code{fold} works through the list elements from first to last. The |
477 | following shows a list reversal and the calls it makes, | |
a0e07ba4 | 478 | |
1e181a08 KR |
479 | @example |
480 | (fold cons '() '(1 2 3)) | |
a0e07ba4 | 481 | |
1e181a08 KR |
482 | (cons 1 '()) |
483 | (cons 2 '(1)) | |
484 | (cons 3 '(2 1) | |
485 | @result{} (3 2 1) | |
486 | @end example | |
a0e07ba4 | 487 | |
1e181a08 KR |
488 | @code{fold-right} works through the list elements from last to first, |
489 | ie.@: from the right. So for example the following finds the longest | |
490 | string, and the last among equal longest, | |
491 | ||
492 | @example | |
493 | (fold-right (lambda (str prev) | |
494 | (if (> (string-length str) (string-length prev)) | |
495 | str | |
496 | prev)) | |
497 | "" | |
498 | '("x" "abc" "xyz" "jk")) | |
499 | @result{} "xyz" | |
500 | @end example | |
a0e07ba4 | 501 | |
1e181a08 KR |
502 | If @var{lst1} through @var{lstN} have different lengths, @code{fold} |
503 | stops when the end of the shortest is reached; @code{fold-right} | |
504 | commences at the last element of the shortest. Ie.@: elements past | |
505 | the length of the shortest are ignored in the other @var{lst}s. At | |
506 | least one @var{lst} must be non-circular. | |
507 | ||
508 | @code{fold} should be preferred over @code{fold-right} if the order of | |
509 | processing doesn't matter, or can be arranged either way, since | |
510 | @code{fold} is a little more efficient. | |
511 | ||
512 | The way @code{fold} builds a result from iterating is quite general, | |
513 | it can do more than other iterations like say @code{map} or | |
514 | @code{filter}. The following for example removes adjacent duplicate | |
515 | elements from a list, | |
516 | ||
517 | @example | |
518 | (define (delete-adjacent-duplicates lst) | |
519 | (fold-right (lambda (elem ret) | |
520 | (if (equal? elem (first ret)) | |
521 | ret | |
522 | (cons elem ret))) | |
523 | (list (last lst)) | |
524 | lst)) | |
525 | (delete-adjacent-duplicates '(1 2 3 3 4 4 4 5)) | |
526 | @result{} (1 2 3 4 5) | |
527 | @end example | |
528 | ||
529 | Clearly the same sort of thing can be done with a @code{for-each} and | |
5f708db6 KR |
530 | a variable in which to build the result, but a self-contained |
531 | @var{proc} can be re-used in multiple contexts, where a | |
532 | @code{for-each} would have to be written out each time. | |
a0e07ba4 NJ |
533 | @end deffn |
534 | ||
1e181a08 KR |
535 | @deffn {Scheme Procedure} pair-fold proc init lst1 @dots{} lstN |
536 | @deffnx {Scheme Procedure} pair-fold-right proc init lst1 @dots{} lstN | |
537 | The same as @code{fold} and @code{fold-right}, but apply @var{proc} to | |
538 | the pairs of the lists instead of the list elements. | |
a0e07ba4 NJ |
539 | @end deffn |
540 | ||
5f708db6 KR |
541 | @deffn {Scheme Procedure} reduce proc default lst |
542 | @deffnx {Scheme Procedure} reduce-right proc default lst | |
543 | @code{reduce} is a variant of @code{fold}, where the first call to | |
544 | @var{proc} is on two elements from @var{lst}, rather than one element | |
545 | and a given initial value. | |
1e181a08 | 546 | |
5f708db6 KR |
547 | If @var{lst} is empty, @code{reduce} returns @var{default} (this is |
548 | the only use for @var{default}). If @var{lst} has just one element | |
549 | then that's the return value. Otherwise @var{proc} is called on the | |
550 | elements of @var{lst}. | |
1e181a08 | 551 | |
5f708db6 KR |
552 | Each @var{proc} call is @code{(@var{proc} @var{elem} @var{previous})}, |
553 | where @var{elem} is from @var{lst} (the second and subsequent elements | |
554 | of @var{lst}), and @var{previous} is the return from the previous call | |
555 | to @var{proc}. The first element of @var{lst} is the @var{previous} | |
556 | for the first call to @var{proc}. | |
1e181a08 | 557 | |
5f708db6 KR |
558 | For example, the following adds a list of numbers, the calls made to |
559 | @code{+} are shown. (Of course @code{+} accepts multiple arguments | |
560 | and can add a list directly, with @code{apply}.) | |
1e181a08 KR |
561 | |
562 | @example | |
5f708db6 KR |
563 | (reduce + 0 '(5 6 7)) @result{} 18 |
564 | ||
565 | (+ 6 5) @result{} 11 | |
566 | (+ 7 11) @result{} 18 | |
1e181a08 KR |
567 | @end example |
568 | ||
5f708db6 KR |
569 | @code{reduce} can be used instead of @code{fold} where the @var{init} |
570 | value is an ``identity'', meaning a value which under @var{proc} | |
571 | doesn't change the result, in this case 0 is an identity since | |
572 | @code{(+ 5 0)} is just 5. @code{reduce} avoids that unnecessary call. | |
1e181a08 KR |
573 | |
574 | @code{reduce-right} is a similar variation on @code{fold-right}, | |
5f708db6 KR |
575 | working from the end (ie.@: the right) of @var{lst}. The last element |
576 | of @var{lst} is the @var{previous} for the first call to @var{proc}, | |
577 | and the @var{elem} values go from the second last. | |
1e181a08 KR |
578 | |
579 | @code{reduce} should be preferred over @code{reduce-right} if the | |
580 | order of processing doesn't matter, or can be arranged either way, | |
581 | since @code{reduce} is a little more efficient. | |
a0e07ba4 NJ |
582 | @end deffn |
583 | ||
8f85c0c6 | 584 | @deffn {Scheme Procedure} unfold p f g seed [tail-gen] |
a0e07ba4 NJ |
585 | @code{unfold} is defined as follows: |
586 | ||
587 | @lisp | |
588 | (unfold p f g seed) = | |
589 | (if (p seed) (tail-gen seed) | |
590 | (cons (f seed) | |
591 | (unfold p f g (g seed)))) | |
592 | @end lisp | |
593 | ||
594 | @table @var | |
595 | @item p | |
596 | Determines when to stop unfolding. | |
597 | ||
598 | @item f | |
599 | Maps each seed value to the corresponding list element. | |
600 | ||
601 | @item g | |
602 | Maps each seed value to next seed valu. | |
603 | ||
604 | @item seed | |
605 | The state value for the unfold. | |
606 | ||
607 | @item tail-gen | |
608 | Creates the tail of the list; defaults to @code{(lambda (x) '())}. | |
609 | @end table | |
610 | ||
611 | @var{g} produces a series of seed values, which are mapped to list | |
612 | elements by @var{f}. These elements are put into a list in | |
613 | left-to-right order, and @var{p} tells when to stop unfolding. | |
614 | @end deffn | |
615 | ||
8f85c0c6 | 616 | @deffn {Scheme Procedure} unfold-right p f g seed [tail] |
a0e07ba4 NJ |
617 | Construct a list with the following loop. |
618 | ||
619 | @lisp | |
620 | (let lp ((seed seed) (lis tail)) | |
621 | (if (p seed) lis | |
622 | (lp (g seed) | |
623 | (cons (f seed) lis)))) | |
624 | @end lisp | |
625 | ||
626 | @table @var | |
627 | @item p | |
628 | Determines when to stop unfolding. | |
629 | ||
630 | @item f | |
631 | Maps each seed value to the corresponding list element. | |
632 | ||
633 | @item g | |
634 | Maps each seed value to next seed valu. | |
635 | ||
636 | @item seed | |
637 | The state value for the unfold. | |
638 | ||
639 | @item tail-gen | |
640 | Creates the tail of the list; defaults to @code{(lambda (x) '())}. | |
641 | @end table | |
642 | ||
643 | @end deffn | |
644 | ||
8f85c0c6 | 645 | @deffn {Scheme Procedure} map f lst1 lst2 @dots{} |
a0e07ba4 NJ |
646 | Map the procedure over the list(s) @var{lst1}, @var{lst2}, @dots{} and |
647 | return a list containing the results of the procedure applications. | |
648 | This procedure is extended with respect to R5RS, because the argument | |
649 | lists may have different lengths. The result list will have the same | |
650 | length as the shortest argument lists. The order in which @var{f} | |
651 | will be applied to the list element(s) is not specified. | |
652 | @end deffn | |
653 | ||
8f85c0c6 | 654 | @deffn {Scheme Procedure} for-each f lst1 lst2 @dots{} |
a0e07ba4 NJ |
655 | Apply the procedure @var{f} to each pair of corresponding elements of |
656 | the list(s) @var{lst1}, @var{lst2}, @dots{}. The return value is not | |
657 | specified. This procedure is extended with respect to R5RS, because | |
658 | the argument lists may have different lengths. The shortest argument | |
659 | list determines the number of times @var{f} is called. @var{f} will | |
85a9b4ed | 660 | be applied to the list elements in left-to-right order. |
a0e07ba4 NJ |
661 | |
662 | @end deffn | |
663 | ||
8f85c0c6 NJ |
664 | @deffn {Scheme Procedure} append-map f lst1 lst2 @dots{} |
665 | @deffnx {Scheme Procedure} append-map! f lst1 lst2 @dots{} | |
12991fed | 666 | Equivalent to |
a0e07ba4 NJ |
667 | |
668 | @lisp | |
12991fed | 669 | (apply append (map f clist1 clist2 ...)) |
a0e07ba4 NJ |
670 | @end lisp |
671 | ||
12991fed | 672 | and |
a0e07ba4 NJ |
673 | |
674 | @lisp | |
12991fed | 675 | (apply append! (map f clist1 clist2 ...)) |
a0e07ba4 NJ |
676 | @end lisp |
677 | ||
678 | Map @var{f} over the elements of the lists, just as in the @code{map} | |
679 | function. However, the results of the applications are appended | |
680 | together to make the final result. @code{append-map} uses | |
681 | @code{append} to append the results together; @code{append-map!} uses | |
682 | @code{append!}. | |
683 | ||
684 | The dynamic order in which the various applications of @var{f} are | |
685 | made is not specified. | |
686 | @end deffn | |
687 | ||
8f85c0c6 | 688 | @deffn {Scheme Procedure} map! f lst1 lst2 @dots{} |
a0e07ba4 NJ |
689 | Linear-update variant of @code{map} -- @code{map!} is allowed, but not |
690 | required, to alter the cons cells of @var{lst1} to construct the | |
691 | result list. | |
692 | ||
693 | The dynamic order in which the various applications of @var{f} are | |
694 | made is not specified. In the n-ary case, @var{lst2}, @var{lst3}, | |
695 | @dots{} must have at least as many elements as @var{lst1}. | |
696 | @end deffn | |
697 | ||
8f85c0c6 | 698 | @deffn {Scheme Procedure} pair-for-each f lst1 lst2 @dots{} |
a0e07ba4 NJ |
699 | Like @code{for-each}, but applies the procedure @var{f} to the pairs |
700 | from which the argument lists are constructed, instead of the list | |
701 | elements. The return value is not specified. | |
702 | @end deffn | |
703 | ||
8f85c0c6 | 704 | @deffn {Scheme Procedure} filter-map f lst1 lst2 @dots{} |
a0e07ba4 NJ |
705 | Like @code{map}, but only results from the applications of @var{f} |
706 | which are true are saved in the result list. | |
707 | @end deffn | |
708 | ||
709 | ||
710 | @node SRFI-1 Filtering and Partitioning | |
3229f68b | 711 | @subsubsection Filtering and Partitioning |
7c2e18cd KR |
712 | @cindex list filter |
713 | @cindex list partition | |
a0e07ba4 NJ |
714 | |
715 | @c FIXME::martin: Review me! | |
716 | ||
717 | Filtering means to collect all elements from a list which satisfy a | |
718 | specific condition. Partitioning a list means to make two groups of | |
719 | list elements, one which contains the elements satisfying a condition, | |
720 | and the other for the elements which don't. | |
721 | ||
60e25dc4 KR |
722 | The @code{filter} and @code{filter!} functions are implemented in the |
723 | Guile core, @xref{List Modification}. | |
a0e07ba4 | 724 | |
8f85c0c6 NJ |
725 | @deffn {Scheme Procedure} partition pred lst |
726 | @deffnx {Scheme Procedure} partition! pred lst | |
193239f1 KR |
727 | Split @var{lst} into those elements which do and don't satisfy the |
728 | predicate @var{pred}. | |
a0e07ba4 | 729 | |
193239f1 KR |
730 | The return is two values (@pxref{Multiple Values}), the first being a |
731 | list of all elements from @var{lst} which satisfy @var{pred}, the | |
732 | second a list of those which do not. | |
733 | ||
734 | The elements in the result lists are in the same order as in @var{lst} | |
735 | but the order in which the calls @code{(@var{pred} elem)} are made on | |
736 | the list elements is unspecified. | |
737 | ||
738 | @code{partition} does not change @var{lst}, but one of the returned | |
739 | lists may share a tail with it. @code{partition!} may modify | |
740 | @var{lst} to construct its return. | |
a0e07ba4 NJ |
741 | @end deffn |
742 | ||
8f85c0c6 NJ |
743 | @deffn {Scheme Procedure} remove pred lst |
744 | @deffnx {Scheme Procedure} remove! pred lst | |
a0e07ba4 NJ |
745 | Return a list containing all elements from @var{lst} which do not |
746 | satisfy the predicate @var{pred}. The elements in the result list | |
747 | have the same order as in @var{lst}. The order in which @var{pred} is | |
748 | applied to the list elements is not specified. | |
749 | ||
750 | @code{remove!} is allowed, but not required to modify the structure of | |
751 | the input list. | |
752 | @end deffn | |
753 | ||
754 | ||
755 | @node SRFI-1 Searching | |
3229f68b | 756 | @subsubsection Searching |
7c2e18cd | 757 | @cindex list search |
a0e07ba4 NJ |
758 | |
759 | @c FIXME::martin: Review me! | |
760 | ||
761 | The procedures for searching elements in lists either accept a | |
762 | predicate or a comparison object for determining which elements are to | |
763 | be searched. | |
764 | ||
8f85c0c6 | 765 | @deffn {Scheme Procedure} find pred lst |
a0e07ba4 NJ |
766 | Return the first element of @var{lst} which satisfies the predicate |
767 | @var{pred} and @code{#f} if no such element is found. | |
768 | @end deffn | |
769 | ||
8f85c0c6 | 770 | @deffn {Scheme Procedure} find-tail pred lst |
a0e07ba4 NJ |
771 | Return the first pair of @var{lst} whose @sc{car} satisfies the |
772 | predicate @var{pred} and @code{#f} if no such element is found. | |
773 | @end deffn | |
774 | ||
8f85c0c6 NJ |
775 | @deffn {Scheme Procedure} take-while pred lst |
776 | @deffnx {Scheme Procedure} take-while! pred lst | |
a0e07ba4 NJ |
777 | Return the longest initial prefix of @var{lst} whose elements all |
778 | satisfy the predicate @var{pred}. | |
779 | ||
780 | @code{take-while!} is allowed, but not required to modify the input | |
781 | list while producing the result. | |
782 | @end deffn | |
783 | ||
8f85c0c6 | 784 | @deffn {Scheme Procedure} drop-while pred lst |
a0e07ba4 NJ |
785 | Drop the longest initial prefix of @var{lst} whose elements all |
786 | satisfy the predicate @var{pred}. | |
787 | @end deffn | |
788 | ||
8f85c0c6 NJ |
789 | @deffn {Scheme Procedure} span pred lst |
790 | @deffnx {Scheme Procedure} span! pred lst | |
791 | @deffnx {Scheme Procedure} break pred lst | |
792 | @deffnx {Scheme Procedure} break! pred lst | |
a0e07ba4 NJ |
793 | @code{span} splits the list @var{lst} into the longest initial prefix |
794 | whose elements all satisfy the predicate @var{pred}, and the remaining | |
795 | tail. @code{break} inverts the sense of the predicate. | |
796 | ||
797 | @code{span!} and @code{break!} are allowed, but not required to modify | |
798 | the structure of the input list @var{lst} in order to produce the | |
799 | result. | |
3e73b6f9 KR |
800 | |
801 | Note that the name @code{break} conflicts with the @code{break} | |
802 | binding established by @code{while} (@pxref{while do}). Applications | |
803 | wanting to use @code{break} from within a @code{while} loop will need | |
804 | to make a new define under a different name. | |
a0e07ba4 NJ |
805 | @end deffn |
806 | ||
62705beb KR |
807 | @deffn {Scheme Procedure} any pred lst1 lst2 @dots{} lstN |
808 | Test whether any set of elements from @var{lst1} @dots{} lstN | |
809 | satisfies @var{pred}. If so the return value is the return from the | |
810 | successful @var{pred} call, or if not the return is @code{#f}. | |
811 | ||
812 | Each @var{pred} call is @code{(@var{pred} @var{elem1} @dots{} | |
813 | @var{elemN})} taking an element from each @var{lst}. The calls are | |
814 | made successively for the first, second, etc elements of the lists, | |
815 | stopping when @var{pred} returns non-@code{#f}, or when the end of the | |
816 | shortest list is reached. | |
817 | ||
818 | The @var{pred} call on the last set of elements (ie.@: when the end of | |
819 | the shortest list has been reached), if that point is reached, is a | |
820 | tail call. | |
821 | @end deffn | |
822 | ||
823 | @deffn {Scheme Procedure} every pred lst1 lst2 @dots{} lstN | |
824 | Test whether every set of elements from @var{lst1} @dots{} lstN | |
825 | satisfies @var{pred}. If so the return value is the return from the | |
826 | final @var{pred} call, or if not the return is @code{#f}. | |
827 | ||
828 | Each @var{pred} call is @code{(@var{pred} @var{elem1} @dots{} | |
829 | @var{elemN})} taking an element from each @var{lst}. The calls are | |
830 | made successively for the first, second, etc elements of the lists, | |
831 | stopping if @var{pred} returns @code{#f}, or when the end of any of | |
832 | the lists is reached. | |
833 | ||
834 | The @var{pred} call on the last set of elements (ie.@: when the end of | |
835 | the shortest list has been reached) is a tail call. | |
836 | ||
837 | If one of @var{lst1} @dots{} @var{lstN} is empty then no calls to | |
838 | @var{pred} are made, and the return is @code{#t}. | |
a0e07ba4 NJ |
839 | @end deffn |
840 | ||
0166e7f2 | 841 | @deffn {Scheme Procedure} list-index pred lst1 @dots{} lstN |
d1736abf KR |
842 | Return the index of the first set of elements, one from each of |
843 | @var{lst1}@dots{}@var{lstN}, which satisfies @var{pred}. | |
844 | ||
845 | @var{pred} is called as @code{(@var{pred} elem1 @dots{} elemN)}. | |
846 | Searching stops when the end of the shortest @var{lst} is reached. | |
847 | The return index starts from 0 for the first set of elements. If no | |
848 | set of elements pass then the return is @code{#f}. | |
0166e7f2 KR |
849 | |
850 | @example | |
851 | (list-index odd? '(2 4 6 9)) @result{} 3 | |
852 | (list-index = '(1 2 3) '(3 1 2)) @result{} #f | |
853 | @end example | |
a0e07ba4 NJ |
854 | @end deffn |
855 | ||
8f85c0c6 | 856 | @deffn {Scheme Procedure} member x lst [=] |
a0e07ba4 | 857 | Return the first sublist of @var{lst} whose @sc{car} is equal to |
ca04a5ae | 858 | @var{x}. If @var{x} does not appear in @var{lst}, return @code{#f}. |
ea6ea01b | 859 | |
ca04a5ae KR |
860 | Equality is determined by @code{equal?}, or by the equality predicate |
861 | @var{=} if given. @var{=} is called @code{(= @var{x} elem)}, | |
862 | ie.@: with the given @var{x} first, so for example to find the first | |
863 | element greater than 5, | |
864 | ||
865 | @example | |
866 | (member 5 '(3 5 1 7 2 9) <) @result{} (7 2 9) | |
867 | @end example | |
868 | ||
869 | This version of @code{member} extends the core @code{member} | |
870 | (@pxref{List Searching}) by accepting an equality predicate. | |
a0e07ba4 NJ |
871 | @end deffn |
872 | ||
873 | ||
874 | @node SRFI-1 Deleting | |
3229f68b | 875 | @subsubsection Deleting |
7c2e18cd | 876 | @cindex list delete |
a0e07ba4 | 877 | |
8f85c0c6 NJ |
878 | @deffn {Scheme Procedure} delete x lst [=] |
879 | @deffnx {Scheme Procedure} delete! x lst [=] | |
b6b9376a KR |
880 | Return a list containing the elements of @var{lst} but with those |
881 | equal to @var{x} deleted. The returned elements will be in the same | |
882 | order as they were in @var{lst}. | |
883 | ||
884 | Equality is determined by the @var{=} predicate, or @code{equal?} if | |
885 | not given. An equality call is made just once for each element, but | |
886 | the order in which the calls are made on the elements is unspecified. | |
a0e07ba4 | 887 | |
243bdb63 | 888 | The equality calls are always @code{(= x elem)}, ie.@: the given @var{x} |
b6b9376a KR |
889 | is first. This means for instance elements greater than 5 can be |
890 | deleted with @code{(delete 5 lst <)}. | |
891 | ||
892 | @code{delete} does not modify @var{lst}, but the return might share a | |
893 | common tail with @var{lst}. @code{delete!} may modify the structure | |
894 | of @var{lst} to construct its return. | |
ea6ea01b | 895 | |
4eb21177 KR |
896 | These functions extend the core @code{delete} and @code{delete!} |
897 | (@pxref{List Modification}) in accepting an equality predicate. See | |
898 | also @code{lset-difference} (@pxref{SRFI-1 Set Operations}) for | |
899 | deleting multiple elements from a list. | |
a0e07ba4 NJ |
900 | @end deffn |
901 | ||
8f85c0c6 NJ |
902 | @deffn {Scheme Procedure} delete-duplicates lst [=] |
903 | @deffnx {Scheme Procedure} delete-duplicates! lst [=] | |
b6b9376a KR |
904 | Return a list containing the elements of @var{lst} but without |
905 | duplicates. | |
906 | ||
907 | When elements are equal, only the first in @var{lst} is retained. | |
908 | Equal elements can be anywhere in @var{lst}, they don't have to be | |
909 | adjacent. The returned list will have the retained elements in the | |
910 | same order as they were in @var{lst}. | |
911 | ||
912 | Equality is determined by the @var{=} predicate, or @code{equal?} if | |
913 | not given. Calls @code{(= x y)} are made with element @var{x} being | |
914 | before @var{y} in @var{lst}. A call is made at most once for each | |
915 | combination, but the sequence of the calls across the elements is | |
916 | unspecified. | |
917 | ||
918 | @code{delete-duplicates} does not modify @var{lst}, but the return | |
919 | might share a common tail with @var{lst}. @code{delete-duplicates!} | |
920 | may modify the structure of @var{lst} to construct its return. | |
921 | ||
922 | In the worst case, this is an @math{O(N^2)} algorithm because it must | |
923 | check each element against all those preceding it. For long lists it | |
924 | is more efficient to sort and then compare only adjacent elements. | |
a0e07ba4 NJ |
925 | @end deffn |
926 | ||
927 | ||
928 | @node SRFI-1 Association Lists | |
3229f68b | 929 | @subsubsection Association Lists |
7c2e18cd KR |
930 | @cindex association list |
931 | @cindex alist | |
a0e07ba4 NJ |
932 | |
933 | @c FIXME::martin: Review me! | |
934 | ||
935 | Association lists are described in detail in section @ref{Association | |
936 | Lists}. The present section only documents the additional procedures | |
937 | for dealing with association lists defined by SRFI-1. | |
938 | ||
8f85c0c6 | 939 | @deffn {Scheme Procedure} assoc key alist [=] |
a0e07ba4 NJ |
940 | Return the pair from @var{alist} which matches @var{key}. Equality is |
941 | determined by @var{=}, which defaults to @code{equal?} if not given. | |
942 | @var{alist} must be an association lists---a list of pairs. | |
ea6ea01b KR |
943 | |
944 | This function extends the core @code{assoc} by accepting an equality | |
945 | predicate. (@pxref{Association Lists}) | |
a0e07ba4 NJ |
946 | @end deffn |
947 | ||
8f85c0c6 | 948 | @deffn {Scheme Procedure} alist-cons key datum alist |
5e5999f9 KR |
949 | Cons a new association @var{key} and @var{datum} onto @var{alist} and |
950 | return the result. This is equivalent to | |
a0e07ba4 NJ |
951 | |
952 | @lisp | |
953 | (cons (cons @var{key} @var{datum}) @var{alist}) | |
954 | @end lisp | |
955 | ||
5e5999f9 KR |
956 | @code{acons} (@pxref{Adding or Setting Alist Entries}) in the Guile |
957 | core does the same thing. | |
a0e07ba4 NJ |
958 | @end deffn |
959 | ||
8f85c0c6 | 960 | @deffn {Scheme Procedure} alist-copy alist |
a0e07ba4 NJ |
961 | Return a newly allocated copy of @var{alist}, that means that the |
962 | spine of the list as well as the pairs are copied. | |
963 | @end deffn | |
964 | ||
8f85c0c6 NJ |
965 | @deffn {Scheme Procedure} alist-delete key alist [=] |
966 | @deffnx {Scheme Procedure} alist-delete! key alist [=] | |
bd35f1f0 KR |
967 | Return a list containing the elements of @var{alist} but with those |
968 | elements whose keys are equal to @var{key} deleted. The returned | |
969 | elements will be in the same order as they were in @var{alist}. | |
a0e07ba4 | 970 | |
bd35f1f0 KR |
971 | Equality is determined by the @var{=} predicate, or @code{equal?} if |
972 | not given. The order in which elements are tested is unspecified, but | |
973 | each equality call is made @code{(= key alistkey)}, ie. the given | |
974 | @var{key} parameter is first and the key from @var{alist} second. | |
975 | This means for instance all associations with a key greater than 5 can | |
976 | be removed with @code{(alist-delete 5 alist <)}. | |
977 | ||
978 | @code{alist-delete} does not modify @var{alist}, but the return might | |
979 | share a common tail with @var{alist}. @code{alist-delete!} may modify | |
980 | the list structure of @var{alist} to construct its return. | |
a0e07ba4 NJ |
981 | @end deffn |
982 | ||
983 | ||
984 | @node SRFI-1 Set Operations | |
3229f68b | 985 | @subsubsection Set Operations on Lists |
7c2e18cd | 986 | @cindex list set operation |
a0e07ba4 | 987 | |
4eb21177 KR |
988 | Lists can be used to represent sets of objects. The procedures in |
989 | this section operate on such lists as sets. | |
990 | ||
991 | Note that lists are not an efficient way to implement large sets. The | |
9aa0c3dd | 992 | procedures here typically take time @math{@var{m}@cross{}@var{n}} when |
4eb21177 KR |
993 | operating on @var{m} and @var{n} element lists. Other data structures |
994 | like trees, bitsets (@pxref{Bit Vectors}) or hash tables (@pxref{Hash | |
995 | Tables}) are faster. | |
996 | ||
997 | All these procedures take an equality predicate as the first argument. | |
998 | This predicate is used for testing the objects in the list sets for | |
999 | sameness. This predicate must be consistent with @code{eq?} | |
1000 | (@pxref{Equality}) in the sense that if two list elements are | |
1001 | @code{eq?} then they must also be equal under the predicate. This | |
1002 | simply means a given object must be equal to itself. | |
a0e07ba4 | 1003 | |
4eb21177 KR |
1004 | @deffn {Scheme Procedure} lset<= = list1 list2 @dots{} |
1005 | Return @code{#t} if each list is a subset of the one following it. | |
1006 | Ie.@: @var{list1} a subset of @var{list2}, @var{list2} a subset of | |
1007 | @var{list3}, etc, for as many lists as given. If only one list or no | |
1008 | lists are given then the return is @code{#t}. | |
1009 | ||
1010 | A list @var{x} is a subset of @var{y} if each element of @var{x} is | |
1011 | equal to some element in @var{y}. Elements are compared using the | |
1012 | given @var{=} procedure, called as @code{(@var{=} xelem yelem)}. | |
1013 | ||
1014 | @example | |
1015 | (lset<= eq?) @result{} #t | |
1016 | (lset<= eqv? '(1 2 3) '(1)) @result{} #f | |
1017 | (lset<= eqv? '(1 3 2) '(4 3 1 2)) @result{} #t | |
1018 | @end example | |
a0e07ba4 NJ |
1019 | @end deffn |
1020 | ||
8f85c0c6 | 1021 | @deffn {Scheme Procedure} lset= = list1 list2 @dots{} |
4eb21177 KR |
1022 | Return @code{#t} if all argument lists are set-equal. @var{list1} is |
1023 | compared to @var{list2}, @var{list2} to @var{list3}, etc, for as many | |
1024 | lists as given. If only one list or no lists are given then the | |
1025 | return is @code{#t}. | |
1026 | ||
1027 | Two lists @var{x} and @var{y} are set-equal if each element of @var{x} | |
1028 | is equal to some element of @var{y} and conversely each element of | |
1029 | @var{y} is equal to some element of @var{x}. The order of the | |
1030 | elements in the lists doesn't matter. Element equality is determined | |
1031 | with the given @var{=} procedure, called as @code{(@var{=} xelem | |
1032 | yelem)}, but exactly which calls are made is unspecified. | |
1033 | ||
1034 | @example | |
1035 | (lset= eq?) @result{} #t | |
1036 | (lset= eqv? '(1 2 3) '(3 2 1)) @result{} #t | |
1037 | (lset= string-ci=? '("a" "A" "b") '("B" "b" "a")) @result{} #t | |
1038 | @end example | |
a0e07ba4 NJ |
1039 | @end deffn |
1040 | ||
4eb21177 KR |
1041 | @deffn {Scheme Procedure} lset-adjoin = list elem1 @dots{} |
1042 | Add to @var{list} any of the given @var{elem}s not already in the | |
1043 | list. @var{elem}s are @code{cons}ed onto the start of @var{list} (so | |
1044 | the return shares a common tail with @var{list}), but the order | |
1045 | they're added is unspecified. | |
1046 | ||
1047 | The given @var{=} procedure is used for comparing elements, called as | |
1048 | @code{(@var{=} listelem elem)}, ie.@: the second argument is one of | |
1049 | the given @var{elem} parameters. | |
1050 | ||
1051 | @example | |
1052 | (lset-adjoin eqv? '(1 2 3) 4 1 5) @result{} (5 4 1 2 3) | |
1053 | @end example | |
a0e07ba4 NJ |
1054 | @end deffn |
1055 | ||
4eb21177 KR |
1056 | @deffn {Scheme Procedure} lset-union = list1 list2 @dots{} |
1057 | @deffnx {Scheme Procedure} lset-union! = list1 list2 @dots{} | |
1058 | Return the union of the argument list sets. The result is built by | |
1059 | taking the union of @var{list1} and @var{list2}, then the union of | |
1060 | that with @var{list3}, etc, for as many lists as given. For one list | |
1061 | argument that list itself is the result, for no list arguments the | |
1062 | result is the empty list. | |
1063 | ||
1064 | The union of two lists @var{x} and @var{y} is formed as follows. If | |
1065 | @var{x} is empty then the result is @var{y}. Otherwise start with | |
1066 | @var{x} as the result and consider each @var{y} element (from first to | |
1067 | last). A @var{y} element not equal to something already in the result | |
1068 | is @code{cons}ed onto the result. | |
1069 | ||
1070 | The given @var{=} procedure is used for comparing elements, called as | |
1071 | @code{(@var{=} relem yelem)}. The first argument is from the result | |
1072 | accumulated so far, and the second is from the list being union-ed in. | |
1073 | But exactly which calls are made is otherwise unspecified. | |
1074 | ||
1075 | Notice that duplicate elements in @var{list1} (or the first non-empty | |
1076 | list) are preserved, but that repeated elements in subsequent lists | |
1077 | are only added once. | |
1078 | ||
1079 | @example | |
1080 | (lset-union eqv?) @result{} () | |
1081 | (lset-union eqv? '(1 2 3)) @result{} (1 2 3) | |
1082 | (lset-union eqv? '(1 2 1 3) '(2 4 5) '(5)) @result{} (5 4 1 2 1 3) | |
1083 | @end example | |
1084 | ||
1085 | @code{lset-union} doesn't change the given lists but the result may | |
1086 | share a tail with the first non-empty list. @code{lset-union!} can | |
1087 | modify all of the given lists to form the result. | |
a0e07ba4 NJ |
1088 | @end deffn |
1089 | ||
8f85c0c6 NJ |
1090 | @deffn {Scheme Procedure} lset-intersection = list1 list2 @dots{} |
1091 | @deffnx {Scheme Procedure} lset-intersection! = list1 list2 @dots{} | |
4eb21177 KR |
1092 | Return the intersection of @var{list1} with the other argument lists, |
1093 | meaning those elements of @var{list1} which are also in all of | |
1094 | @var{list2} etc. For one list argument, just that list is returned. | |
1095 | ||
1096 | The test for an element of @var{list1} to be in the return is simply | |
1097 | that it's equal to some element in each of @var{list2} etc. Notice | |
1098 | this means an element appearing twice in @var{list1} but only once in | |
1099 | each of @var{list2} etc will go into the return twice. The return has | |
1100 | its elements in the same order as they were in @var{list1}. | |
1101 | ||
1102 | The given @var{=} procedure is used for comparing elements, called as | |
1103 | @code{(@var{=} elem1 elemN)}. The first argument is from @var{list1} | |
1104 | and the second is from one of the subsequent lists. But exactly which | |
1105 | calls are made and in what order is unspecified. | |
1106 | ||
1107 | @example | |
1108 | (lset-intersection eqv? '(x y)) @result{} (x y) | |
1109 | (lset-intersection eqv? '(1 2 3) '(4 3 2)) @result{} (2 3) | |
1110 | (lset-intersection eqv? '(1 1 2 2) '(1 2) '(2 1) '(2)) @result{} (2 2) | |
1111 | @end example | |
1112 | ||
1113 | The return from @code{lset-intersection} may share a tail with | |
1114 | @var{list1}. @code{lset-intersection!} may modify @var{list1} to form | |
1115 | its result. | |
a0e07ba4 NJ |
1116 | @end deffn |
1117 | ||
8f85c0c6 NJ |
1118 | @deffn {Scheme Procedure} lset-difference = list1 list2 @dots{} |
1119 | @deffnx {Scheme Procedure} lset-difference! = list1 list2 @dots{} | |
4eb21177 KR |
1120 | Return @var{list1} with any elements in @var{list2}, @var{list3} etc |
1121 | removed (ie.@: subtracted). For one list argument, just that list is | |
1122 | returned. | |
1123 | ||
1124 | The given @var{=} procedure is used for comparing elements, called as | |
1125 | @code{(@var{=} elem1 elemN)}. The first argument is from @var{list1} | |
1126 | and the second from one of the subsequent lists. But exactly which | |
1127 | calls are made and in what order is unspecified. | |
a0e07ba4 | 1128 | |
4eb21177 KR |
1129 | @example |
1130 | (lset-difference eqv? '(x y)) @result{} (x y) | |
1131 | (lset-difference eqv? '(1 2 3) '(3 1)) @result{} (2) | |
1132 | (lset-difference eqv? '(1 2 3) '(3) '(2)) @result{} (1) | |
1133 | @end example | |
1134 | ||
1135 | The return from @code{lset-difference} may share a tail with | |
1136 | @var{list1}. @code{lset-difference!} may modify @var{list1} to form | |
1137 | its result. | |
a0e07ba4 NJ |
1138 | @end deffn |
1139 | ||
8f85c0c6 NJ |
1140 | @deffn {Scheme Procedure} lset-diff+intersection = list1 list2 @dots{} |
1141 | @deffnx {Scheme Procedure} lset-diff+intersection! = list1 list2 @dots{} | |
4eb21177 KR |
1142 | Return two values (@pxref{Multiple Values}), the difference and |
1143 | intersection of the argument lists as per @code{lset-difference} and | |
1144 | @code{lset-intersection} above. | |
1145 | ||
1146 | For two list arguments this partitions @var{list1} into those elements | |
1147 | of @var{list1} which are in @var{list2} and not in @var{list2}. (But | |
1148 | for more than two arguments there can be elements of @var{list1} which | |
1149 | are neither part of the difference nor the intersection.) | |
1150 | ||
1151 | One of the return values from @code{lset-diff+intersection} may share | |
1152 | a tail with @var{list1}. @code{lset-diff+intersection!} may modify | |
1153 | @var{list1} to form its results. | |
1154 | @end deffn | |
1155 | ||
1156 | @deffn {Scheme Procedure} lset-xor = list1 list2 @dots{} | |
1157 | @deffnx {Scheme Procedure} lset-xor! = list1 list2 @dots{} | |
1158 | Return an XOR of the argument lists. For two lists this means those | |
1159 | elements which are in exactly one of the lists. For more than two | |
1160 | lists it means those elements which appear in an odd number of the | |
1161 | lists. | |
1162 | ||
1163 | To be precise, the XOR of two lists @var{x} and @var{y} is formed by | |
1164 | taking those elements of @var{x} not equal to any element of @var{y}, | |
1165 | plus those elements of @var{y} not equal to any element of @var{x}. | |
1166 | Equality is determined with the given @var{=} procedure, called as | |
1167 | @code{(@var{=} e1 e2)}. One argument is from @var{x} and the other | |
1168 | from @var{y}, but which way around is unspecified. Exactly which | |
1169 | calls are made is also unspecified, as is the order of the elements in | |
1170 | the result. | |
1171 | ||
1172 | @example | |
1173 | (lset-xor eqv? '(x y)) @result{} (x y) | |
1174 | (lset-xor eqv? '(1 2 3) '(4 3 2)) @result{} (4 1) | |
1175 | @end example | |
1176 | ||
1177 | The return from @code{lset-xor} may share a tail with one of the list | |
1178 | arguments. @code{lset-xor!} may modify @var{list1} to form its | |
1179 | result. | |
a0e07ba4 NJ |
1180 | @end deffn |
1181 | ||
1182 | ||
1183 | @node SRFI-2 | |
3229f68b | 1184 | @subsection SRFI-2 - and-let* |
8742c48b | 1185 | @cindex SRFI-2 |
a0e07ba4 | 1186 | |
4fd0db14 KR |
1187 | @noindent |
1188 | The following syntax can be obtained with | |
a0e07ba4 | 1189 | |
4fd0db14 KR |
1190 | @lisp |
1191 | (use-modules (srfi srfi-2)) | |
1192 | @end lisp | |
a0e07ba4 | 1193 | |
4fd0db14 KR |
1194 | @deffn {library syntax} and-let* (clause @dots{}) body @dots{} |
1195 | A combination of @code{and} and @code{let*}. | |
1196 | ||
1197 | Each @var{clause} is evaluated in turn, and if @code{#f} is obtained | |
1198 | then evaluation stops and @code{#f} is returned. If all are | |
1199 | non-@code{#f} then @var{body} is evaluated and the last form gives the | |
6b1a6e4c KR |
1200 | return value, or if @var{body} is empty then the result is @code{#t}. |
1201 | Each @var{clause} should be one of the following, | |
4fd0db14 KR |
1202 | |
1203 | @table @code | |
1204 | @item (symbol expr) | |
1205 | Evaluate @var{expr}, check for @code{#f}, and bind it to @var{symbol}. | |
1206 | Like @code{let*}, that binding is available to subsequent clauses. | |
1207 | @item (expr) | |
1208 | Evaluate @var{expr} and check for @code{#f}. | |
1209 | @item symbol | |
1210 | Get the value bound to @var{symbol} and check for @code{#f}. | |
1211 | @end table | |
a0e07ba4 | 1212 | |
4fd0db14 KR |
1213 | Notice that @code{(expr)} has an ``extra'' pair of parentheses, for |
1214 | instance @code{((eq? x y))}. One way to remember this is to imagine | |
1215 | the @code{symbol} in @code{(symbol expr)} is omitted. | |
a0e07ba4 | 1216 | |
4fd0db14 KR |
1217 | @code{and-let*} is good for calculations where a @code{#f} value means |
1218 | termination, but where a non-@code{#f} value is going to be needed in | |
1219 | subsequent expressions. | |
1220 | ||
1221 | The following illustrates this, it returns text between brackets | |
1222 | @samp{[...]} in a string, or @code{#f} if there are no such brackets | |
1223 | (ie.@: either @code{string-index} gives @code{#f}). | |
1224 | ||
1225 | @example | |
1226 | (define (extract-brackets str) | |
1227 | (and-let* ((start (string-index str #\[)) | |
1228 | (end (string-index str #\] start))) | |
1229 | (substring str (1+ start) end))) | |
1230 | @end example | |
1231 | ||
1232 | The following shows plain variables and expressions tested too. | |
1233 | @code{diagnostic-levels} is taken to be an alist associating a | |
1234 | diagnostic type with a level. @code{str} is printed only if the type | |
1235 | is known and its level is high enough. | |
1236 | ||
1237 | @example | |
1238 | (define (show-diagnostic type str) | |
1239 | (and-let* (want-diagnostics | |
1240 | (level (assq-ref diagnostic-levels type)) | |
1241 | ((>= level current-diagnostic-level))) | |
1242 | (display str))) | |
1243 | @end example | |
1244 | ||
1245 | The advantage of @code{and-let*} is that an extended sequence of | |
1246 | expressions and tests doesn't require lots of nesting as would arise | |
1247 | from separate @code{and} and @code{let*}, or from @code{cond} with | |
1248 | @code{=>}. | |
1249 | ||
1250 | @end deffn | |
a0e07ba4 NJ |
1251 | |
1252 | ||
1253 | @node SRFI-4 | |
3229f68b | 1254 | @subsection SRFI-4 - Homogeneous numeric vector datatypes |
8742c48b | 1255 | @cindex SRFI-4 |
a0e07ba4 | 1256 | |
e6b226b9 | 1257 | The SRFI-4 procedures and data types are always available, @xref{Uniform |
3dd6e0cf | 1258 | Numeric Vectors}. |
a0e07ba4 NJ |
1259 | |
1260 | @node SRFI-6 | |
3229f68b | 1261 | @subsection SRFI-6 - Basic String Ports |
8742c48b | 1262 | @cindex SRFI-6 |
a0e07ba4 NJ |
1263 | |
1264 | SRFI-6 defines the procedures @code{open-input-string}, | |
1265 | @code{open-output-string} and @code{get-output-string}. These | |
1266 | procedures are included in the Guile core, so using this module does not | |
1267 | make any difference at the moment. But it is possible that support for | |
1268 | SRFI-6 will be factored out of the core library in the future, so using | |
1269 | this module does not hurt, after all. | |
1270 | ||
1271 | @node SRFI-8 | |
3229f68b | 1272 | @subsection SRFI-8 - receive |
8742c48b | 1273 | @cindex SRFI-8 |
a0e07ba4 NJ |
1274 | |
1275 | @code{receive} is a syntax for making the handling of multiple-value | |
1276 | procedures easier. It is documented in @xref{Multiple Values}. | |
1277 | ||
1278 | ||
1279 | @node SRFI-9 | |
3229f68b | 1280 | @subsection SRFI-9 - define-record-type |
8742c48b | 1281 | @cindex SRFI-9 |
7c2e18cd | 1282 | @cindex record |
a0e07ba4 | 1283 | |
6afe385d KR |
1284 | This SRFI is a syntax for defining new record types and creating |
1285 | predicate, constructor, and field getter and setter functions. In | |
1286 | Guile this is simply an alternate interface to the core record | |
1287 | functionality (@pxref{Records}). It can be used with, | |
a0e07ba4 | 1288 | |
6afe385d KR |
1289 | @example |
1290 | (use-modules (srfi srfi-9)) | |
1291 | @end example | |
1292 | ||
1293 | @deffn {library syntax} define-record-type type @* (constructor fieldname @dots{}) @* predicate @* (fieldname accessor [modifier]) @dots{} | |
1294 | @sp 1 | |
1295 | Create a new record type, and make various @code{define}s for using | |
1296 | it. This syntax can only occur at the top-level, not nested within | |
1297 | some other form. | |
1298 | ||
1299 | @var{type} is bound to the record type, which is as per the return | |
1300 | from the core @code{make-record-type}. @var{type} also provides the | |
1301 | name for the record, as per @code{record-type-name}. | |
1302 | ||
1303 | @var{constructor} is bound to a function to be called as | |
1304 | @code{(@var{constructor} fieldval @dots{})} to create a new record of | |
1305 | this type. The arguments are initial values for the fields, one | |
1306 | argument for each field, in the order they appear in the | |
1307 | @code{define-record-type} form. | |
1308 | ||
1309 | The @var{fieldname}s provide the names for the record fields, as per | |
1310 | the core @code{record-type-fields} etc, and are referred to in the | |
1311 | subsequent accessor/modifier forms. | |
1312 | ||
1313 | @var{predictate} is bound to a function to be called as | |
1314 | @code{(@var{predicate} obj)}. It returns @code{#t} or @code{#f} | |
1315 | according to whether @var{obj} is a record of this type. | |
1316 | ||
1317 | Each @var{accessor} is bound to a function to be called | |
1318 | @code{(@var{accessor} record)} to retrieve the respective field from a | |
1319 | @var{record}. Similarly each @var{modifier} is bound to a function to | |
1320 | be called @code{(@var{modifier} record val)} to set the respective | |
1321 | field in a @var{record}. | |
1322 | @end deffn | |
1323 | ||
1324 | @noindent | |
1325 | An example will illustrate typical usage, | |
a0e07ba4 NJ |
1326 | |
1327 | @example | |
6afe385d KR |
1328 | (define-record-type employee-type |
1329 | (make-employee name age salary) | |
1330 | employee? | |
1331 | (name get-employee-name) | |
1332 | (age get-employee-age set-employee-age) | |
1333 | (salary get-employee-salary set-employee-salary)) | |
a0e07ba4 NJ |
1334 | @end example |
1335 | ||
6afe385d KR |
1336 | This creates a new employee data type, with name, age and salary |
1337 | fields. Accessor functions are created for each field, but no | |
1338 | modifier function for the name (the intention in this example being | |
1339 | that it's established only when an employee object is created). These | |
1340 | can all then be used as for example, | |
a0e07ba4 NJ |
1341 | |
1342 | @example | |
6afe385d KR |
1343 | employee-type @result{} #<record-type employee-type> |
1344 | ||
1345 | (define fred (make-employee "Fred" 45 20000.00)) | |
1346 | ||
1347 | (employee? fred) @result{} #t | |
1348 | (get-employee-age fred) @result{} 45 | |
1349 | (set-employee-salary fred 25000.00) ;; pay rise | |
a0e07ba4 NJ |
1350 | @end example |
1351 | ||
6afe385d KR |
1352 | The functions created by @code{define-record-type} are ordinary |
1353 | top-level @code{define}s. They can be redefined or @code{set!} as | |
1354 | desired, exported from a module, etc. | |
1355 | ||
a0e07ba4 NJ |
1356 | |
1357 | @node SRFI-10 | |
3229f68b | 1358 | @subsection SRFI-10 - Hash-Comma Reader Extension |
8742c48b | 1359 | @cindex SRFI-10 |
a0e07ba4 NJ |
1360 | |
1361 | @cindex hash-comma | |
1362 | @cindex #,() | |
633acbe2 KR |
1363 | This SRFI implements a reader extension @code{#,()} called hash-comma. |
1364 | It allows the reader to give new kinds of objects, for use both in | |
1365 | data and as constants or literals in source code. This feature is | |
1366 | available with | |
a0e07ba4 | 1367 | |
633acbe2 KR |
1368 | @example |
1369 | (use-modules (srfi srfi-10)) | |
1370 | @end example | |
1371 | ||
1372 | @noindent | |
1373 | The new read syntax is of the form | |
a0e07ba4 NJ |
1374 | |
1375 | @example | |
633acbe2 | 1376 | #,(@var{tag} @var{arg}@dots{}) |
a0e07ba4 NJ |
1377 | @end example |
1378 | ||
633acbe2 KR |
1379 | @noindent |
1380 | where @var{tag} is a symbol and the @var{arg}s are objects taken as | |
1381 | parameters. @var{tag}s are registered with the following procedure. | |
a0e07ba4 | 1382 | |
633acbe2 KR |
1383 | @deffn {Scheme Procedure} define-reader-ctor tag proc |
1384 | Register @var{proc} as the constructor for a hash-comma read syntax | |
1385 | starting with symbol @var{tag}, ie. @nicode{#,(@var{tag} arg@dots{})}. | |
1386 | @var{proc} is called with the given arguments @code{(@var{proc} | |
1387 | arg@dots{})} and the object it returns is the result of the read. | |
1388 | @end deffn | |
a0e07ba4 | 1389 | |
633acbe2 KR |
1390 | @noindent |
1391 | For example, a syntax giving a list of @var{N} copies of an object. | |
1392 | ||
1393 | @example | |
1394 | (define-reader-ctor 'repeat | |
1395 | (lambda (obj reps) | |
1396 | (make-list reps obj))) | |
1397 | ||
1398 | (display '#,(repeat 99 3)) | |
1399 | @print{} (99 99 99) | |
1400 | @end example | |
1401 | ||
1402 | Notice the quote @nicode{'} when the @nicode{#,( )} is used. The | |
1403 | @code{repeat} handler returns a list and the program must quote to use | |
1404 | it literally, the same as any other list. Ie. | |
1405 | ||
1406 | @example | |
1407 | (display '#,(repeat 99 3)) | |
a0e07ba4 | 1408 | @result{} |
633acbe2 KR |
1409 | (display '(99 99 99)) |
1410 | @end example | |
a0e07ba4 | 1411 | |
633acbe2 KR |
1412 | When a handler returns an object which is self-evaluating, like a |
1413 | number or a string, then there's no need for quoting, just as there's | |
1414 | no need when giving those directly as literals. For example an | |
1415 | addition, | |
a0e07ba4 | 1416 | |
633acbe2 KR |
1417 | @example |
1418 | (define-reader-ctor 'sum | |
1419 | (lambda (x y) | |
1420 | (+ x y))) | |
1421 | (display #,(sum 123 456)) @print{} 579 | |
1422 | @end example | |
1423 | ||
1424 | A typical use for @nicode{#,()} is to get a read syntax for objects | |
1425 | which don't otherwise have one. For example, the following allows a | |
1426 | hash table to be given literally, with tags and values, ready for fast | |
1427 | lookup. | |
1428 | ||
1429 | @example | |
1430 | (define-reader-ctor 'hash | |
1431 | (lambda elems | |
1432 | (let ((table (make-hash-table))) | |
1433 | (for-each (lambda (elem) | |
01549abb KR |
1434 | (apply hash-set! table elem)) |
1435 | elems) | |
633acbe2 KR |
1436 | table))) |
1437 | ||
1438 | (define (animal->family animal) | |
1439 | (hash-ref '#,(hash ("tiger" "cat") | |
1440 | ("lion" "cat") | |
1441 | ("wolf" "dog")) | |
1442 | animal)) | |
1443 | ||
1444 | (animal->family "lion") @result{} "cat" | |
1445 | @end example | |
1446 | ||
1447 | Or for example the following is a syntax for a compiled regular | |
1448 | expression (@pxref{Regular Expressions}). | |
1449 | ||
1450 | @example | |
1451 | (use-modules (ice-9 regex)) | |
1452 | ||
1453 | (define-reader-ctor 'regexp make-regexp) | |
1454 | ||
1455 | (define (extract-angs str) | |
1456 | (let ((match (regexp-exec '#,(regexp "<([A-Z0-9]+)>") str))) | |
1457 | (and match | |
1458 | (match:substring match 1)))) | |
1459 | ||
1460 | (extract-angs "foo <BAR> quux") @result{} "BAR" | |
1461 | @end example | |
1462 | ||
1463 | @sp 1 | |
1464 | @nicode{#,()} is somewhat similar to @code{define-macro} | |
1465 | (@pxref{Macros}) in that handler code is run to produce a result, but | |
1466 | @nicode{#,()} operates at the read stage, so it can appear in data for | |
1467 | @code{read} (@pxref{Scheme Read}), not just in code to be executed. | |
1468 | ||
1469 | Because @nicode{#,()} is handled at read-time it has no direct access | |
1470 | to variables etc. A symbol in the arguments is just a symbol, not a | |
1471 | variable reference. The arguments are essentially constants, though | |
1472 | the handler procedure can use them in any complicated way it might | |
1473 | want. | |
1474 | ||
1475 | Once @code{(srfi srfi-10)} has loaded, @nicode{#,()} is available | |
1476 | globally, there's no need to use @code{(srfi srfi-10)} in later | |
1477 | modules. Similarly the tags registered are global and can be used | |
1478 | anywhere once registered. | |
1479 | ||
1480 | There's no attempt to record what previous @nicode{#,()} forms have | |
1481 | been seen, if two identical forms occur then two calls are made to the | |
1482 | handler procedure. The handler might like to maintain a cache or | |
1483 | similar to avoid making copies of large objects, depending on expected | |
1484 | usage. | |
1485 | ||
1486 | In code the best uses of @nicode{#,()} are generally when there's a | |
1487 | lot of objects of a particular kind as literals or constants. If | |
1488 | there's just a few then some local variables and initializers are | |
1489 | fine, but that becomes tedious and error prone when there's a lot, and | |
1490 | the anonymous and compact syntax of @nicode{#,()} is much better. | |
a0e07ba4 NJ |
1491 | |
1492 | ||
1493 | @node SRFI-11 | |
3229f68b | 1494 | @subsection SRFI-11 - let-values |
8742c48b | 1495 | @cindex SRFI-11 |
a0e07ba4 | 1496 | |
8742c48b KR |
1497 | @findex let-values |
1498 | @findex let-values* | |
a0e07ba4 NJ |
1499 | This module implements the binding forms for multiple values |
1500 | @code{let-values} and @code{let-values*}. These forms are similar to | |
1501 | @code{let} and @code{let*} (@pxref{Local Bindings}), but they support | |
1502 | binding of the values returned by multiple-valued expressions. | |
1503 | ||
1504 | Write @code{(use-modules (srfi srfi-11))} to make the bindings | |
1505 | available. | |
1506 | ||
1507 | @lisp | |
1508 | (let-values (((x y) (values 1 2)) | |
1509 | ((z f) (values 3 4))) | |
1510 | (+ x y z f)) | |
1511 | @result{} | |
1512 | 10 | |
1513 | @end lisp | |
1514 | ||
1515 | @code{let-values} performs all bindings simultaneously, which means that | |
1516 | no expression in the binding clauses may refer to variables bound in the | |
1517 | same clause list. @code{let-values*}, on the other hand, performs the | |
1518 | bindings sequentially, just like @code{let*} does for single-valued | |
1519 | expressions. | |
1520 | ||
1521 | ||
1522 | @node SRFI-13 | |
3229f68b | 1523 | @subsection SRFI-13 - String Library |
8742c48b | 1524 | @cindex SRFI-13 |
a0e07ba4 | 1525 | |
5676b4fa | 1526 | The SRFI-13 procedures are always available, @xref{Strings}. |
a0e07ba4 NJ |
1527 | |
1528 | @node SRFI-14 | |
3229f68b | 1529 | @subsection SRFI-14 - Character-set Library |
8742c48b | 1530 | @cindex SRFI-14 |
a0e07ba4 | 1531 | |
050ab45f MV |
1532 | The SRFI-14 data type and procedures are always available, |
1533 | @xref{Character Sets}. | |
a0e07ba4 NJ |
1534 | |
1535 | @node SRFI-16 | |
3229f68b | 1536 | @subsection SRFI-16 - case-lambda |
8742c48b | 1537 | @cindex SRFI-16 |
7c2e18cd KR |
1538 | @cindex variable arity |
1539 | @cindex arity, variable | |
a0e07ba4 NJ |
1540 | |
1541 | @c FIXME::martin: Review me! | |
1542 | ||
8742c48b | 1543 | @findex case-lambda |
a0e07ba4 NJ |
1544 | The syntactic form @code{case-lambda} creates procedures, just like |
1545 | @code{lambda}, but has syntactic extensions for writing procedures of | |
1546 | varying arity easier. | |
1547 | ||
1548 | The syntax of the @code{case-lambda} form is defined in the following | |
1549 | EBNF grammar. | |
1550 | ||
1551 | @example | |
1552 | @group | |
1553 | <case-lambda> | |
1554 | --> (case-lambda <case-lambda-clause>) | |
1555 | <case-lambda-clause> | |
1556 | --> (<formals> <definition-or-command>*) | |
1557 | <formals> | |
1558 | --> (<identifier>*) | |
1559 | | (<identifier>* . <identifier>) | |
1560 | | <identifier> | |
1561 | @end group | |
1562 | @end example | |
1563 | ||
1564 | The value returned by a @code{case-lambda} form is a procedure which | |
1565 | matches the number of actual arguments against the formals in the | |
1566 | various clauses, in order. @dfn{Formals} means a formal argument list | |
1567 | just like with @code{lambda} (@pxref{Lambda}). The first matching clause | |
1568 | is selected, the corresponding values from the actual parameter list are | |
1569 | bound to the variable names in the clauses and the body of the clause is | |
1570 | evaluated. If no clause matches, an error is signalled. | |
1571 | ||
1572 | The following (silly) definition creates a procedure @var{foo} which | |
1573 | acts differently, depending on the number of actual arguments. If one | |
1574 | argument is given, the constant @code{#t} is returned, two arguments are | |
1575 | added and if more arguments are passed, their product is calculated. | |
1576 | ||
1577 | @lisp | |
1578 | (define foo (case-lambda | |
1579 | ((x) #t) | |
1580 | ((x y) (+ x y)) | |
1581 | (z | |
1582 | (apply * z)))) | |
1583 | (foo 'bar) | |
1584 | @result{} | |
1585 | #t | |
1586 | (foo 2 4) | |
1587 | @result{} | |
1588 | 6 | |
1589 | (foo 3 3 3) | |
1590 | @result{} | |
1591 | 27 | |
1592 | (foo) | |
1593 | @result{} | |
1594 | 1 | |
1595 | @end lisp | |
1596 | ||
1597 | The last expression evaluates to 1 because the last clause is matched, | |
1598 | @var{z} is bound to the empty list and the following multiplication, | |
1599 | applied to zero arguments, yields 1. | |
1600 | ||
1601 | ||
1602 | @node SRFI-17 | |
3229f68b | 1603 | @subsection SRFI-17 - Generalized set! |
8742c48b | 1604 | @cindex SRFI-17 |
a0e07ba4 NJ |
1605 | |
1606 | This is an implementation of SRFI-17: Generalized set! | |
1607 | ||
8742c48b | 1608 | @findex getter-with-setter |
a0e07ba4 NJ |
1609 | It exports the Guile procedure @code{make-procedure-with-setter} under |
1610 | the SRFI name @code{getter-with-setter} and exports the standard | |
1611 | procedures @code{car}, @code{cdr}, @dots{}, @code{cdddr}, | |
1612 | @code{string-ref} and @code{vector-ref} as procedures with setters, as | |
1613 | required by the SRFI. | |
1614 | ||
1615 | SRFI-17 was heavily criticized during its discussion period but it was | |
1616 | finalized anyway. One issue was its concept of globally associating | |
1617 | setter @dfn{properties} with (procedure) values, which is non-Schemy. | |
1618 | For this reason, this implementation chooses not to provide a way to set | |
1619 | the setter of a procedure. In fact, @code{(set! (setter @var{proc}) | |
1620 | @var{setter})} signals an error. The only way to attach a setter to a | |
1621 | procedure is to create a new object (a @dfn{procedure with setter}) via | |
1622 | the @code{getter-with-setter} procedure. This procedure is also | |
1623 | specified in the SRFI. Using it avoids the described problems. | |
1624 | ||
12991fed TTN |
1625 | |
1626 | @node SRFI-19 | |
3229f68b | 1627 | @subsection SRFI-19 - Time/Date Library |
8742c48b | 1628 | @cindex SRFI-19 |
7c2e18cd KR |
1629 | @cindex time |
1630 | @cindex date | |
12991fed | 1631 | |
85600a0f KR |
1632 | This is an implementation of the SRFI-19 time/date library. The |
1633 | functions and variables described here are provided by | |
12991fed TTN |
1634 | |
1635 | @example | |
85600a0f | 1636 | (use-modules (srfi srfi-19)) |
12991fed TTN |
1637 | @end example |
1638 | ||
7d281fa5 KR |
1639 | @strong{Caution}: The current code in this module incorrectly extends |
1640 | the Gregorian calendar leap year rule back prior to the introduction | |
1641 | of those reforms in 1582 (or the appropriate year in various | |
1642 | countries). The Julian calendar was used prior to 1582, and there | |
1643 | were 10 days skipped for the reform, but the code doesn't implement | |
1644 | that. | |
1645 | ||
1646 | This will be fixed some time. Until then calculations for 1583 | |
1647 | onwards are correct, but prior to that any day/month/year and day of | |
1648 | the week calculations are wrong. | |
1649 | ||
85600a0f KR |
1650 | @menu |
1651 | * SRFI-19 Introduction:: | |
1652 | * SRFI-19 Time:: | |
1653 | * SRFI-19 Date:: | |
1654 | * SRFI-19 Time/Date conversions:: | |
1655 | * SRFI-19 Date to string:: | |
1656 | * SRFI-19 String to date:: | |
1657 | @end menu | |
12991fed | 1658 | |
85600a0f | 1659 | @node SRFI-19 Introduction |
3229f68b | 1660 | @subsubsection SRFI-19 Introduction |
85600a0f KR |
1661 | |
1662 | @cindex universal time | |
1663 | @cindex atomic time | |
1664 | @cindex UTC | |
1665 | @cindex TAI | |
1666 | This module implements time and date representations and calculations, | |
1667 | in various time systems, including universal time (UTC) and atomic | |
1668 | time (TAI). | |
1669 | ||
1670 | For those not familiar with these time systems, TAI is based on a | |
1671 | fixed length second derived from oscillations of certain atoms. UTC | |
1672 | differs from TAI by an integral number of seconds, which is increased | |
1673 | or decreased at announced times to keep UTC aligned to a mean solar | |
1674 | day (the orbit and rotation of the earth are not quite constant). | |
1675 | ||
1676 | @cindex leap second | |
1677 | So far, only increases in the TAI | |
1678 | @tex | |
1679 | $\leftrightarrow$ | |
1680 | @end tex | |
1681 | @ifnottex | |
1682 | <-> | |
1683 | @end ifnottex | |
1684 | UTC difference have been needed. Such an increase is a ``leap | |
1685 | second'', an extra second of TAI introduced at the end of a UTC day. | |
1686 | When working entirely within UTC this is never seen, every day simply | |
1687 | has 86400 seconds. But when converting from TAI to a UTC date, an | |
1688 | extra 23:59:60 is present, where normally a day would end at 23:59:59. | |
1689 | Effectively the UTC second from 23:59:59 to 00:00:00 has taken two TAI | |
1690 | seconds. | |
1691 | ||
1692 | @cindex system clock | |
1693 | In the current implementation, the system clock is assumed to be UTC, | |
1694 | and a table of leap seconds in the code converts to TAI. See comments | |
1695 | in @file{srfi-19.scm} for how to update this table. | |
1696 | ||
1697 | @cindex julian day | |
1698 | @cindex modified julian day | |
1699 | Also, for those not familiar with the terminology, a @dfn{Julian Day} | |
1700 | is a real number which is a count of days and fraction of a day, in | |
1701 | UTC, starting from -4713-01-01T12:00:00Z, ie.@: midday Monday 1 Jan | |
7c2e18cd KR |
1702 | 4713 B.C. A @dfn{Modified Julian Day} is the same, but starting from |
1703 | 1858-11-17T00:00:00Z, ie.@: midnight 17 November 1858 UTC. That time | |
1704 | is julian day 2400000.5. | |
85600a0f KR |
1705 | |
1706 | @c The SRFI-1 spec says -4714-11-24T12:00:00Z (November 24, -4714 at | |
1707 | @c noon, UTC), but this is incorrect. It looks like it might have | |
1708 | @c arisen from the code incorrectly treating years a multiple of 100 | |
7c2e18cd | 1709 | @c but not 400 prior to 1582 as non-leap years, where instead the Julian |
85600a0f KR |
1710 | @c calendar should be used so all multiples of 4 before 1582 are leap |
1711 | @c years. | |
1712 | ||
1713 | ||
1714 | @node SRFI-19 Time | |
3229f68b | 1715 | @subsubsection SRFI-19 Time |
85600a0f KR |
1716 | @cindex time |
1717 | ||
1718 | A @dfn{time} object has type, seconds and nanoseconds fields | |
1719 | representing a point in time starting from some epoch. This is an | |
1720 | arbitrary point in time, not just a time of day. Although times are | |
1721 | represented in nanoseconds, the actual resolution may be lower. | |
1722 | ||
1723 | The following variables hold the possible time types. For instance | |
1724 | @code{(current-time time-process)} would give the current CPU process | |
1725 | time. | |
1726 | ||
1727 | @defvar time-utc | |
1728 | Universal Coordinated Time (UTC). | |
1729 | @cindex UTC | |
1730 | @end defvar | |
12991fed | 1731 | |
85600a0f KR |
1732 | @defvar time-tai |
1733 | International Atomic Time (TAI). | |
1734 | @cindex TAI | |
1735 | @end defvar | |
12991fed | 1736 | |
85600a0f KR |
1737 | @defvar time-monotonic |
1738 | Monotonic time, meaning a monotonically increasing time starting from | |
1739 | an unspecified epoch. | |
12991fed | 1740 | |
85600a0f KR |
1741 | Note that in the current implementation @code{time-monotonic} is the |
1742 | same as @code{time-tai}, and unfortunately is therefore affected by | |
1743 | adjustments to the system clock. Perhaps this will change in the | |
1744 | future. | |
1745 | @end defvar | |
12991fed | 1746 | |
85600a0f KR |
1747 | @defvar time-duration |
1748 | A duration, meaning simply a difference between two times. | |
1749 | @end defvar | |
12991fed | 1750 | |
85600a0f KR |
1751 | @defvar time-process |
1752 | CPU time spent in the current process, starting from when the process | |
1753 | began. | |
1754 | @cindex process time | |
1755 | @end defvar | |
12991fed | 1756 | |
85600a0f KR |
1757 | @defvar time-thread |
1758 | CPU time spent in the current thread. Not currently implemented. | |
1759 | @cindex thread time | |
1760 | @end defvar | |
12991fed | 1761 | |
85600a0f KR |
1762 | @sp 1 |
1763 | @defun time? obj | |
1764 | Return @code{#t} if @var{obj} is a time object, or @code{#f} if not. | |
1765 | @end defun | |
1766 | ||
1767 | @defun make-time type nanoseconds seconds | |
1768 | Create a time object with the given @var{type}, @var{seconds} and | |
1769 | @var{nanoseconds}. | |
1770 | @end defun | |
1771 | ||
1772 | @defun time-type time | |
1773 | @defunx time-nanosecond time | |
1774 | @defunx time-second time | |
1775 | @defunx set-time-type! time type | |
1776 | @defunx set-time-nanosecond! time nsec | |
1777 | @defunx set-time-second! time sec | |
1778 | Get or set the type, seconds or nanoseconds fields of a time object. | |
1779 | ||
1780 | @code{set-time-type!} merely changes the field, it doesn't convert the | |
1781 | time value. For conversions, see @ref{SRFI-19 Time/Date conversions}. | |
1782 | @end defun | |
1783 | ||
1784 | @defun copy-time time | |
1785 | Return a new time object, which is a copy of the given @var{time}. | |
1786 | @end defun | |
1787 | ||
1788 | @defun current-time [type] | |
1789 | Return the current time of the given @var{type}. The default | |
1790 | @var{type} is @code{time-utc}. | |
1791 | ||
1792 | Note that the name @code{current-time} conflicts with the Guile core | |
1793 | @code{current-time} function (@pxref{Time}). Applications wanting to | |
1794 | use both will need to use a different name for one of them. | |
1795 | @end defun | |
1796 | ||
1797 | @defun time-resolution [type] | |
1798 | Return the resolution, in nanoseconds, of the given time @var{type}. | |
1799 | The default @var{type} is @code{time-utc}. | |
1800 | @end defun | |
1801 | ||
1802 | @defun time<=? t1 t2 | |
1803 | @defunx time<? t1 t2 | |
1804 | @defunx time=? t1 t2 | |
1805 | @defunx time>=? t1 t2 | |
1806 | @defunx time>? t1 t2 | |
1807 | Return @code{#t} or @code{#f} according to the respective relation | |
1808 | between time objects @var{t1} and @var{t2}. @var{t1} and @var{t2} | |
1809 | must be the same time type. | |
1810 | @end defun | |
1811 | ||
1812 | @defun time-difference t1 t2 | |
1813 | @defunx time-difference! t1 t2 | |
1814 | Return a time object of type @code{time-duration} representing the | |
1815 | period between @var{t1} and @var{t2}. @var{t1} and @var{t2} must be | |
1816 | the same time type. | |
1817 | ||
1818 | @code{time-difference} returns a new time object, | |
1819 | @code{time-difference!} may modify @var{t1} to form its return. | |
1820 | @end defun | |
1821 | ||
1822 | @defun add-duration time duration | |
1823 | @defunx add-duration! time duration | |
1824 | @defunx subtract-duration time duration | |
1825 | @defunx subtract-duration! time duration | |
1826 | Return a time object which is @var{time} with the given @var{duration} | |
1827 | added or subtracted. @var{duration} must be a time object of type | |
1828 | @code{time-duration}. | |
1829 | ||
1830 | @code{add-duration} and @code{subtract-duration} return a new time | |
1831 | object. @code{add-duration!} and @code{subtract-duration!} may modify | |
1832 | the given @var{time} to form their return. | |
1833 | @end defun | |
1834 | ||
1835 | ||
1836 | @node SRFI-19 Date | |
3229f68b | 1837 | @subsubsection SRFI-19 Date |
85600a0f KR |
1838 | @cindex date |
1839 | ||
1840 | A @dfn{date} object represents a date in the Gregorian calendar and a | |
1841 | time of day on that date in some timezone. | |
1842 | ||
1843 | The fields are year, month, day, hour, minute, second, nanoseconds and | |
1844 | timezone. A date object is immutable, its fields can be read but they | |
1845 | cannot be modified once the object is created. | |
1846 | ||
1847 | @defun date? obj | |
1848 | Return @code{#t} if @var{obj} is a date object, or @code{#f} if not. | |
1849 | @end defun | |
1850 | ||
1851 | @defun make-date nsecs seconds minutes hours date month year zone-offset | |
1852 | Create a new date object. | |
1853 | @c | |
1854 | @c FIXME: What can we say about the ranges of the values. The | |
1855 | @c current code looks it doesn't normalize, but expects then in their | |
1856 | @c usual range already. | |
1857 | @c | |
1858 | @end defun | |
1859 | ||
1860 | @defun date-nanosecond date | |
1861 | Nanoseconds, 0 to 999999999. | |
1862 | @end defun | |
1863 | ||
1864 | @defun date-second date | |
7c2e18cd KR |
1865 | Seconds, 0 to 59, or 60 for a leap second. 60 is never seen when working |
1866 | entirely within UTC, it's only when converting to or from TAI. | |
85600a0f KR |
1867 | @end defun |
1868 | ||
1869 | @defun date-minute date | |
1870 | Minutes, 0 to 59. | |
1871 | @end defun | |
1872 | ||
1873 | @defun date-hour date | |
1874 | Hour, 0 to 23. | |
1875 | @end defun | |
1876 | ||
1877 | @defun date-day date | |
1878 | Day of the month, 1 to 31 (or less, according to the month). | |
1879 | @end defun | |
1880 | ||
1881 | @defun date-month date | |
1882 | Month, 1 to 12. | |
1883 | @end defun | |
1884 | ||
1885 | @defun date-year date | |
7c2e18cd KR |
1886 | Year, eg.@: 2003. Dates B.C.@: are negative, eg.@: @math{-46} is 46 |
1887 | B.C. There is no year 0, year @math{-1} is followed by year 1. | |
85600a0f KR |
1888 | @end defun |
1889 | ||
1890 | @defun date-zone-offset date | |
1891 | Time zone, an integer number of seconds east of Greenwich. | |
1892 | @end defun | |
1893 | ||
1894 | @defun date-year-day date | |
1895 | Day of the year, starting from 1 for 1st January. | |
1896 | @end defun | |
1897 | ||
1898 | @defun date-week-day date | |
1899 | Day of the week, starting from 0 for Sunday. | |
1900 | @end defun | |
1901 | ||
1902 | @defun date-week-number date dstartw | |
1903 | Week of the year, ignoring a first partial week. @var{dstartw} is the | |
1904 | day of the week which is taken to start a week, 0 for Sunday, 1 for | |
1905 | Monday, etc. | |
1906 | @c | |
1907 | @c FIXME: The spec doesn't say whether numbering starts at 0 or 1. | |
1908 | @c The code looks like it's 0, if that's the correct intention. | |
1909 | @c | |
1910 | @end defun | |
1911 | ||
1912 | @c The SRFI text doesn't actually give the default for tz-offset, but | |
1913 | @c the reference implementation has the local timezone and the | |
1914 | @c conversions functions all specify that, so it should be ok to | |
1915 | @c document it here. | |
1916 | @c | |
1917 | @defun current-date [tz-offset] | |
7c2e18cd KR |
1918 | Return a date object representing the current date/time, in UTC offset |
1919 | by @var{tz-offset}. @var{tz-offset} is seconds east of Greenwich and | |
1920 | defaults to the local timezone. | |
85600a0f KR |
1921 | @end defun |
1922 | ||
1923 | @defun current-julian-day | |
1924 | @cindex julian day | |
1925 | Return the current Julian Day. | |
1926 | @end defun | |
1927 | ||
1928 | @defun current-modified-julian-day | |
1929 | @cindex modified julian day | |
1930 | Return the current Modified Julian Day. | |
1931 | @end defun | |
1932 | ||
1933 | ||
1934 | @node SRFI-19 Time/Date conversions | |
3229f68b | 1935 | @subsubsection SRFI-19 Time/Date conversions |
7c2e18cd KR |
1936 | @cindex time conversion |
1937 | @cindex date conversion | |
85600a0f KR |
1938 | |
1939 | @defun date->julian-day date | |
1940 | @defunx date->modified-julian-day date | |
1941 | @defunx date->time-monotonic date | |
1942 | @defunx date->time-tai date | |
1943 | @defunx date->time-utc date | |
1944 | @end defun | |
1945 | @defun julian-day->date jdn [tz-offset] | |
1946 | @defunx julian-day->time-monotonic jdn | |
1947 | @defunx julian-day->time-tai jdn | |
1948 | @defunx julian-day->time-utc jdn | |
1949 | @end defun | |
1950 | @defun modified-julian-day->date jdn [tz-offset] | |
1951 | @defunx modified-julian-day->time-monotonic jdn | |
1952 | @defunx modified-julian-day->time-tai jdn | |
1953 | @defunx modified-julian-day->time-utc jdn | |
1954 | @end defun | |
1955 | @defun time-monotonic->date time [tz-offset] | |
1956 | @defunx time-monotonic->time-tai time | |
1957 | @defunx time-monotonic->time-tai! time | |
1958 | @defunx time-monotonic->time-utc time | |
1959 | @defunx time-monotonic->time-utc! time | |
1960 | @end defun | |
1961 | @defun time-tai->date time [tz-offset] | |
1962 | @defunx time-tai->julian-day time | |
1963 | @defunx time-tai->modified-julian-day time | |
1964 | @defunx time-tai->time-monotonic time | |
1965 | @defunx time-tai->time-monotonic! time | |
1966 | @defunx time-tai->time-utc time | |
1967 | @defunx time-tai->time-utc! time | |
1968 | @end defun | |
1969 | @defun time-utc->date time [tz-offset] | |
1970 | @defunx time-utc->julian-day time | |
1971 | @defunx time-utc->modified-julian-day time | |
1972 | @defunx time-utc->time-monotonic time | |
1973 | @defunx time-utc->time-monotonic! time | |
1974 | @defunx time-utc->time-tai time | |
1975 | @defunx time-utc->time-tai! time | |
1976 | @sp 1 | |
1977 | Convert between dates, times and days of the respective types. For | |
1978 | instance @code{time-tai->time-utc} accepts a @var{time} object of type | |
1979 | @code{time-tai} and returns an object of type @code{time-utc}. | |
1980 | ||
85600a0f KR |
1981 | The @code{!} variants may modify their @var{time} argument to form |
1982 | their return. The plain functions create a new object. | |
702e6e09 KR |
1983 | |
1984 | For conversions to dates, @var{tz-offset} is seconds east of | |
1985 | Greenwich. The default is the local timezone, at the given time, as | |
1986 | provided by the system, using @code{localtime} (@pxref{Time}). | |
1987 | ||
1988 | On 32-bit systems, @code{localtime} is limited to a 32-bit | |
1989 | @code{time_t}, so a default @var{tz-offset} is only available for | |
1990 | times between Dec 1901 and Jan 2038. For prior dates an application | |
1991 | might like to use the value in 1902, though some locations have zone | |
1992 | changes prior to that. For future dates an application might like to | |
1993 | assume today's rules extend indefinitely. But for correct daylight | |
1994 | savings transitions it will be necessary to take an offset for the | |
1995 | same day and time but a year in range and which has the same starting | |
1996 | weekday and same leap/non-leap (to support rules like last Sunday in | |
1997 | October). | |
85600a0f KR |
1998 | @end defun |
1999 | ||
2000 | @node SRFI-19 Date to string | |
3229f68b | 2001 | @subsubsection SRFI-19 Date to string |
85600a0f | 2002 | @cindex date to string |
7c2e18cd | 2003 | @cindex string, from date |
85600a0f KR |
2004 | |
2005 | @defun date->string date [format] | |
2006 | Convert a date to a string under the control of a format. | |
2007 | @var{format} should be a string containing @samp{~} escapes, which | |
2008 | will be expanded as per the following conversion table. The default | |
2009 | @var{format} is @samp{~c}, a locale-dependent date and time. | |
2010 | ||
2011 | Many of these conversion characters are the same as POSIX | |
2012 | @code{strftime} (@pxref{Time}), but there are some extras and some | |
2013 | variations. | |
2014 | ||
2015 | @multitable {MMMM} {MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM} | |
2016 | @item @nicode{~~} @tab literal ~ | |
2017 | @item @nicode{~a} @tab locale abbreviated weekday, eg.@: @samp{Sun} | |
2018 | @item @nicode{~A} @tab locale full weekday, eg.@: @samp{Sunday} | |
2019 | @item @nicode{~b} @tab locale abbreviated month, eg.@: @samp{Jan} | |
2020 | @item @nicode{~B} @tab locale full month, eg.@: @samp{January} | |
2021 | @item @nicode{~c} @tab locale date and time, eg.@: @* | |
2022 | @samp{Fri Jul 14 20:28:42-0400 2000} | |
2023 | @item @nicode{~d} @tab day of month, zero padded, @samp{01} to @samp{31} | |
2024 | ||
2025 | @c Spec says d/m/y, reference implementation says m/d/y. | |
2026 | @c Apparently the reference code was the intention, but would like to | |
2027 | @c see an errata published for the spec before contradicting it here. | |
2028 | @c | |
2029 | @c @item @nicode{~D} @tab date @nicode{~d/~m/~y} | |
2030 | ||
2031 | @item @nicode{~e} @tab day of month, blank padded, @samp{ 1} to @samp{31} | |
2032 | @item @nicode{~f} @tab seconds and fractional seconds, | |
2033 | with locale decimal point, eg.@: @samp{5.2} | |
2034 | @item @nicode{~h} @tab same as @nicode{~b} | |
2035 | @item @nicode{~H} @tab hour, 24-hour clock, zero padded, @samp{00} to @samp{23} | |
2036 | @item @nicode{~I} @tab hour, 12-hour clock, zero padded, @samp{01} to @samp{12} | |
2037 | @item @nicode{~j} @tab day of year, zero padded, @samp{001} to @samp{366} | |
2038 | @item @nicode{~k} @tab hour, 24-hour clock, blank padded, @samp{ 0} to @samp{23} | |
2039 | @item @nicode{~l} @tab hour, 12-hour clock, blank padded, @samp{ 1} to @samp{12} | |
2040 | @item @nicode{~m} @tab month, zero padded, @samp{01} to @samp{12} | |
2041 | @item @nicode{~M} @tab minute, zero padded, @samp{00} to @samp{59} | |
2042 | @item @nicode{~n} @tab newline | |
2043 | @item @nicode{~N} @tab nanosecond, zero padded, @samp{000000000} to @samp{999999999} | |
2044 | @item @nicode{~p} @tab locale AM or PM | |
2045 | @item @nicode{~r} @tab time, 12 hour clock, @samp{~I:~M:~S ~p} | |
2046 | @item @nicode{~s} @tab number of full seconds since ``the epoch'' in UTC | |
2047 | @item @nicode{~S} @tab second, zero padded @samp{00} to @samp{60} @* | |
2048 | (usual limit is 59, 60 is a leap second) | |
2049 | @item @nicode{~t} @tab horizontal tab character | |
2050 | @item @nicode{~T} @tab time, 24 hour clock, @samp{~H:~M:~S} | |
2051 | @item @nicode{~U} @tab week of year, Sunday first day of week, | |
2052 | @samp{00} to @samp{52} | |
2053 | @item @nicode{~V} @tab week of year, Monday first day of week, | |
2054 | @samp{01} to @samp{53} | |
2055 | @item @nicode{~w} @tab day of week, 0 for Sunday, @samp{0} to @samp{6} | |
2056 | @item @nicode{~W} @tab week of year, Monday first day of week, | |
2057 | @samp{00} to @samp{52} | |
2058 | ||
2059 | @c The spec has ~x as an apparent duplicate of ~W, and ~X as a locale | |
2060 | @c date. The reference code has ~x as the locale date and ~X as a | |
2061 | @c locale time. The rule is apparently that the code should be | |
2062 | @c believed, but would like to see an errata for the spec before | |
2063 | @c contradicting it here. | |
2064 | @c | |
2065 | @c @item @nicode{~x} @tab week of year, Monday as first day of week, | |
2066 | @c @samp{00} to @samp{53} | |
2067 | @c @item @nicode{~X} @tab locale date, eg.@: @samp{07/31/00} | |
2068 | ||
2069 | @item @nicode{~y} @tab year, two digits, @samp{00} to @samp{99} | |
2070 | @item @nicode{~Y} @tab year, full, eg.@: @samp{2003} | |
2071 | @item @nicode{~z} @tab time zone, RFC-822 style | |
2072 | @item @nicode{~Z} @tab time zone symbol (not currently implemented) | |
2073 | @item @nicode{~1} @tab ISO-8601 date, @samp{~Y-~m-~d} | |
2074 | @item @nicode{~2} @tab ISO-8601 time+zone, @samp{~k:~M:~S~z} | |
2075 | @item @nicode{~3} @tab ISO-8601 time, @samp{~k:~M:~S} | |
2076 | @item @nicode{~4} @tab ISO-8601 date/time+zone, @samp{~Y-~m-~dT~k:~M:~S~z} | |
2077 | @item @nicode{~5} @tab ISO-8601 date/time, @samp{~Y-~m-~dT~k:~M:~S} | |
2078 | @end multitable | |
2079 | @end defun | |
2080 | ||
2081 | Conversions @samp{~D}, @samp{~x} and @samp{~X} are not currently | |
2082 | described here, since the specification and reference implementation | |
2083 | differ. | |
2084 | ||
2085 | Currently Guile doesn't implement any localizations for the above, all | |
2086 | outputs are in English, and the @samp{~c} conversion is POSIX | |
2087 | @code{ctime} style @samp{~a ~b ~d ~H:~M:~S~z ~Y}. This may change in | |
2088 | the future. | |
2089 | ||
2090 | ||
2091 | @node SRFI-19 String to date | |
3229f68b | 2092 | @subsubsection SRFI-19 String to date |
85600a0f | 2093 | @cindex string to date |
7c2e18cd | 2094 | @cindex date, from string |
85600a0f KR |
2095 | |
2096 | @c FIXME: Can we say what happens when an incomplete date is | |
2097 | @c converted? Ie. fields left as 0, or what? The spec seems to be | |
2098 | @c silent on this. | |
2099 | ||
2100 | @defun string->date input template | |
2101 | Convert an @var{input} string to a date under the control of a | |
2102 | @var{template} string. Return a newly created date object. | |
2103 | ||
2104 | Literal characters in @var{template} must match characters in | |
2105 | @var{input} and @samp{~} escapes must match the input forms described | |
2106 | in the table below. ``Skip to'' means characters up to one of the | |
2107 | given type are ignored, or ``no skip'' for no skipping. ``Read'' is | |
2108 | what's then read, and ``Set'' is the field affected in the date | |
2109 | object. | |
2110 | ||
2111 | For example @samp{~Y} skips input characters until a digit is reached, | |
2112 | at which point it expects a year and stores that to the year field of | |
2113 | the date. | |
2114 | ||
2115 | @multitable {MMMM} {@nicode{char-alphabetic?}} {MMMMMMMMMMMMMMMMMMMMMMMMM} {@nicode{date-zone-offset}} | |
2116 | @item | |
2117 | @tab Skip to | |
2118 | @tab Read | |
2119 | @tab Set | |
2120 | ||
2121 | @item @nicode{~~} | |
2122 | @tab no skip | |
2123 | @tab literal ~ | |
2124 | @tab nothing | |
2125 | ||
2126 | @item @nicode{~a} | |
2127 | @tab @nicode{char-alphabetic?} | |
2128 | @tab locale abbreviated weekday name | |
2129 | @tab nothing | |
2130 | ||
2131 | @item @nicode{~A} | |
2132 | @tab @nicode{char-alphabetic?} | |
2133 | @tab locale full weekday name | |
2134 | @tab nothing | |
2135 | ||
2136 | @c Note that the SRFI spec says that ~b and ~B don't set anything, | |
2137 | @c but that looks like a mistake. The reference implementation sets | |
2138 | @c the month field, which seems sensible and is what we describe | |
2139 | @c here. | |
2140 | ||
2141 | @item @nicode{~b} | |
2142 | @tab @nicode{char-alphabetic?} | |
2143 | @tab locale abbreviated month name | |
2144 | @tab @nicode{date-month} | |
2145 | ||
2146 | @item @nicode{~B} | |
2147 | @tab @nicode{char-alphabetic?} | |
2148 | @tab locale full month name | |
2149 | @tab @nicode{date-month} | |
2150 | ||
2151 | @item @nicode{~d} | |
2152 | @tab @nicode{char-numeric?} | |
2153 | @tab day of month | |
2154 | @tab @nicode{date-day} | |
2155 | ||
2156 | @item @nicode{~e} | |
2157 | @tab no skip | |
2158 | @tab day of month, blank padded | |
2159 | @tab @nicode{date-day} | |
2160 | ||
2161 | @item @nicode{~h} | |
2162 | @tab same as @samp{~b} | |
2163 | ||
2164 | @item @nicode{~H} | |
2165 | @tab @nicode{char-numeric?} | |
2166 | @tab hour | |
2167 | @tab @nicode{date-hour} | |
2168 | ||
2169 | @item @nicode{~k} | |
2170 | @tab no skip | |
2171 | @tab hour, blank padded | |
2172 | @tab @nicode{date-hour} | |
2173 | ||
2174 | @item @nicode{~m} | |
2175 | @tab @nicode{char-numeric?} | |
2176 | @tab month | |
2177 | @tab @nicode{date-month} | |
2178 | ||
2179 | @item @nicode{~M} | |
2180 | @tab @nicode{char-numeric?} | |
2181 | @tab minute | |
2182 | @tab @nicode{date-minute} | |
2183 | ||
2184 | @item @nicode{~S} | |
2185 | @tab @nicode{char-numeric?} | |
2186 | @tab second | |
2187 | @tab @nicode{date-second} | |
2188 | ||
2189 | @item @nicode{~y} | |
2190 | @tab no skip | |
2191 | @tab 2-digit year | |
2192 | @tab @nicode{date-year} within 50 years | |
2193 | ||
2194 | @item @nicode{~Y} | |
2195 | @tab @nicode{char-numeric?} | |
2196 | @tab year | |
2197 | @tab @nicode{date-year} | |
2198 | ||
2199 | @item @nicode{~z} | |
2200 | @tab no skip | |
2201 | @tab time zone | |
2202 | @tab date-zone-offset | |
2203 | @end multitable | |
2204 | ||
2205 | Notice that the weekday matching forms don't affect the date object | |
2206 | returned, instead the weekday will be derived from the day, month and | |
2207 | year. | |
2208 | ||
2209 | Currently Guile doesn't implement any localizations for the above, | |
2210 | month and weekday names are always expected in English. This may | |
2211 | change in the future. | |
2212 | @end defun | |
12991fed | 2213 | |
1de8c1ae | 2214 | |
b0b55bd6 | 2215 | @node SRFI-26 |
3229f68b | 2216 | @subsection SRFI-26 - specializing parameters |
1de8c1ae | 2217 | @cindex SRFI-26 |
7c2e18cd KR |
2218 | @cindex parameter specialize |
2219 | @cindex argument specialize | |
2220 | @cindex specialize parameter | |
1de8c1ae KR |
2221 | |
2222 | This SRFI provides a syntax for conveniently specializing selected | |
2223 | parameters of a function. It can be used with, | |
2224 | ||
2225 | @example | |
2226 | (use-modules (srfi srfi-26)) | |
2227 | @end example | |
2228 | ||
2229 | @deffn {library syntax} cut slot @dots{} | |
2230 | @deffnx {library syntax} cute slot @dots{} | |
2231 | Return a new procedure which will make a call (@var{slot} @dots{}) but | |
2232 | with selected parameters specialized to given expressions. | |
2233 | ||
2234 | An example will illustrate the idea. The following is a | |
2235 | specialization of @code{write}, sending output to | |
2236 | @code{my-output-port}, | |
2237 | ||
2238 | @example | |
2239 | (cut write <> my-output-port) | |
2240 | @result{} | |
2241 | (lambda (obj) (write obj my-output-port)) | |
2242 | @end example | |
2243 | ||
2244 | The special symbol @code{<>} indicates a slot to be filled by an | |
2245 | argument to the new procedure. @code{my-output-port} on the other | |
2246 | hand is an expression to be evaluated and passed, ie.@: it specializes | |
2247 | the behaviour of @code{write}. | |
2248 | ||
2249 | @table @nicode | |
2250 | @item <> | |
2251 | A slot to be filled by an argument from the created procedure. | |
2252 | Arguments are assigned to @code{<>} slots in the order they appear in | |
2253 | the @code{cut} form, there's no way to re-arrange arguments. | |
2254 | ||
2255 | The first argument to @code{cut} is usually a procedure (or expression | |
2256 | giving a procedure), but @code{<>} is allowed there too. For example, | |
2257 | ||
2258 | @example | |
2259 | (cut <> 1 2 3) | |
2260 | @result{} | |
2261 | (lambda (proc) (proc 1 2 3)) | |
2262 | @end example | |
2263 | ||
2264 | @item <...> | |
2265 | A slot to be filled by all remaining arguments from the new procedure. | |
2266 | This can only occur at the end of a @code{cut} form. | |
2267 | ||
2268 | For example, a procedure taking a variable number of arguments like | |
2269 | @code{max} but in addition enforcing a lower bound, | |
2270 | ||
2271 | @example | |
2272 | (define my-lower-bound 123) | |
2273 | ||
2274 | (cut max my-lower-bound <...>) | |
2275 | @result{} | |
2276 | (lambda arglist (apply max my-lower-bound arglist)) | |
2277 | @end example | |
2278 | @end table | |
2279 | ||
2280 | For @code{cut} the specializing expressions are evaluated each time | |
2281 | the new procedure is called. For @code{cute} they're evaluated just | |
2282 | once, when the new procedure is created. The name @code{cute} stands | |
2283 | for ``@code{cut} with evaluated arguments''. In all cases the | |
2284 | evaluations take place in an unspecified order. | |
2285 | ||
2286 | The following illustrates the difference between @code{cut} and | |
2287 | @code{cute}, | |
2288 | ||
2289 | @example | |
2290 | (cut format <> "the time is ~s" (current-time)) | |
2291 | @result{} | |
2292 | (lambda (port) (format port "the time is ~s" (current-time))) | |
2293 | ||
2294 | (cute format <> "the time is ~s" (current-time)) | |
2295 | @result{} | |
2296 | (let ((val (current-time))) | |
2297 | (lambda (port) (format port "the time is ~s" val)) | |
2298 | @end example | |
2299 | ||
2300 | (There's no provision for a mixture of @code{cut} and @code{cute} | |
2301 | where some expressions would be evaluated every time but others | |
2302 | evaluated only once.) | |
2303 | ||
2304 | @code{cut} is really just a shorthand for the sort of @code{lambda} | |
2305 | forms shown in the above examples. But notice @code{cut} avoids the | |
2306 | need to name unspecialized parameters, and is more compact. Use in | |
2307 | functional programming style or just with @code{map}, @code{for-each} | |
2308 | or similar is typical. | |
2309 | ||
2310 | @example | |
2311 | (map (cut * 2 <>) '(1 2 3 4)) | |
2312 | ||
2313 | (for-each (cut write <> my-port) my-list) | |
2314 | @end example | |
2315 | @end deffn | |
b0b55bd6 | 2316 | |
8638c417 RB |
2317 | @node SRFI-31 |
2318 | @subsection SRFI-31 - A special form `rec' for recursive evaluation | |
2319 | @cindex SRFI-31 | |
7c2e18cd | 2320 | @cindex recursive expression |
8638c417 RB |
2321 | @findex rec |
2322 | ||
2323 | SRFI-31 defines a special form that can be used to create | |
2324 | self-referential expressions more conveniently. The syntax is as | |
2325 | follows: | |
2326 | ||
2327 | @example | |
2328 | @group | |
2329 | <rec expression> --> (rec <variable> <expression>) | |
2330 | <rec expression> --> (rec (<variable>+) <body>) | |
2331 | @end group | |
2332 | @end example | |
2333 | ||
2334 | The first syntax can be used to create self-referential expressions, | |
2335 | for example: | |
2336 | ||
2337 | @lisp | |
2338 | guile> (define tmp (rec ones (cons 1 (delay ones)))) | |
2339 | @end lisp | |
2340 | ||
2341 | The second syntax can be used to create anonymous recursive functions: | |
2342 | ||
2343 | @lisp | |
2344 | guile> (define tmp (rec (display-n item n) | |
2345 | (if (positive? n) | |
2346 | (begin (display n) (display-n (- n 1)))))) | |
2347 | guile> (tmp 42 3) | |
2348 | 424242 | |
2349 | guile> | |
2350 | @end lisp | |
12991fed | 2351 | |
eeadfda1 KR |
2352 | |
2353 | @node SRFI-39 | |
2354 | @subsection SRFI-39 - Parameters | |
2355 | @cindex SRFI-39 | |
2356 | @cindex parameter object | |
2357 | @tindex Parameter | |
2358 | ||
2359 | This SRFI provides parameter objects, which implement dynamically | |
2360 | bound locations for values. The functions below are available from | |
2361 | ||
2362 | @example | |
2363 | (use-modules (srfi srfi-39)) | |
2364 | @end example | |
2365 | ||
2366 | A parameter object is a procedure. Called with no arguments it | |
2367 | returns its value, called with one argument it sets the value. | |
2368 | ||
2369 | @example | |
2370 | (define my-param (make-parameter 123)) | |
2371 | (my-param) @result{} 123 | |
2372 | (my-param 456) | |
2373 | (my-param) @result{} 456 | |
2374 | @end example | |
2375 | ||
2376 | The @code{parameterize} special form establishes new locations for | |
2377 | parameters, those new locations having effect within the dynamic scope | |
2378 | of the @code{parameterize} body. Leaving restores the previous | |
2379 | locations, or re-entering through a saved continuation will again use | |
2380 | the new locations. | |
2381 | ||
2382 | @example | |
2383 | (parameterize ((my-param 789)) | |
2384 | (my-param) @result{} 789 | |
2385 | ) | |
2386 | (my-param) @result{} 456 | |
2387 | @end example | |
2388 | ||
2389 | Parameters are like dynamically bound variables in other Lisp dialets. | |
2390 | They allow an application to establish parameter settings (as the name | |
2391 | suggests) just for the execution of a particular bit of code, | |
2392 | restoring when done. Examples of such parameters might be | |
2393 | case-sensitivity for a search, or a prompt for user input. | |
2394 | ||
2395 | Global variables are not as good as parameter objects for this sort of | |
2396 | thing. Changes to them are visible to all threads, but in Guile | |
2397 | parameter object locations are per-thread, thereby truely limiting the | |
2398 | effect of @code{parameterize} to just its dynamic execution. | |
2399 | ||
2400 | Passing arguments to functions is thread-safe, but that soon becomes | |
2401 | tedious when there's more than a few or when they need to pass down | |
2402 | through several layers of calls before reaching the point they should | |
2403 | affect. And introducing a new setting to existing code is often | |
2404 | easier with a parameter object than adding arguments. | |
2405 | ||
2406 | ||
2407 | @sp 1 | |
2408 | @defun make-parameter init [converter] | |
2409 | Return a new parameter object, with initial value @var{init}. | |
2410 | ||
2411 | A parameter object is a procedure. When called @code{(param)} it | |
2412 | returns its value, or a call @code{(param val)} sets its value. For | |
2413 | example, | |
2414 | ||
2415 | @example | |
2416 | (define my-param (make-parameter 123)) | |
2417 | (my-param) @result{} 123 | |
2418 | ||
2419 | (my-param 456) | |
2420 | (my-param) @result{} 456 | |
2421 | @end example | |
2422 | ||
2423 | If a @var{converter} is given, then a call @code{(@var{converter} | |
2424 | val)} is made for each value set, its return is the value stored. | |
2425 | Such a call is made for the @var{init} initial value too. | |
2426 | ||
2427 | A @var{converter} allows values to be validated, or put into a | |
2428 | canonical form. For example, | |
2429 | ||
2430 | @example | |
2431 | (define my-param (make-parameter 123 | |
2432 | (lambda (val) | |
2433 | (if (not (number? val)) | |
2434 | (error "must be a number")) | |
2435 | (inexact->exact val)))) | |
2436 | (my-param 0.75) | |
2437 | (my-param) @result{} 3/4 | |
2438 | @end example | |
2439 | @end defun | |
2440 | ||
2441 | @deffn {library syntax} parameterize ((param value) @dots{}) body @dots{} | |
2442 | Establish a new dynamic scope with the given @var{param}s bound to new | |
2443 | locations and set to the given @var{value}s. @var{body} is evaluated | |
2444 | in that environment, the result is the return from the last form in | |
2445 | @var{body}. | |
2446 | ||
2447 | Each @var{param} is an expression which is evaluated to get the | |
2448 | parameter object. Often this will just be the name of a variable | |
2449 | holding the object, but it can be anything that evaluates to a | |
2450 | parameter. | |
2451 | ||
2452 | The @var{param} expressions and @var{value} expressions are all | |
2453 | evaluated before establishing the new dynamic bindings, and they're | |
2454 | evaluated in an unspecified order. | |
2455 | ||
2456 | For example, | |
2457 | ||
2458 | @example | |
2459 | (define prompt (make-parameter "Type something: ")) | |
2460 | (define (get-input) | |
2461 | (display (prompt)) | |
2462 | ...) | |
2463 | ||
2464 | (parameterize ((prompt "Type a number: ")) | |
2465 | (get-input) | |
2466 | ...) | |
2467 | @end example | |
2468 | @end deffn | |
2469 | ||
2470 | @deffn {Parameter object} current-input-port [new-port] | |
2471 | @deffnx {Parameter object} current-output-port [new-port] | |
2472 | @deffnx {Parameter object} current-error-port [new-port] | |
2473 | This SRFI extends the core @code{current-input-port} and | |
2474 | @code{current-output-port}, making them parameter objects. The | |
2475 | Guile-specific @code{current-error-port} is extended too, for | |
2476 | consistency. (@pxref{Default Ports}.) | |
2477 | ||
2478 | This is an upwardly compatible extension, a plain call like | |
2479 | @code{(current-input-port)} still returns the current input port, and | |
2480 | @code{set-current-input-port} can still be used. But the port can now | |
2481 | also be set with @code{(current-input-port my-port)} and bound | |
2482 | dynamically with @code{parameterize}. | |
2483 | @end deffn | |
2484 | ||
2485 | @defun with-parameters* param-list value-list thunk | |
2486 | Establish a new dynamic scope, as per @code{parameterize} above, | |
2487 | taking parameters from @var{param-list} and corresponding values from | |
2488 | @var{values-list}. A call @code{(@var{thunk})} is made in the new | |
2489 | scope and the result from that @var{thunk} is the return from | |
2490 | @code{with-parameters*}. | |
2491 | ||
2492 | This function is a Guile-specific addition to the SRFI, it's similar | |
b4fddbbe | 2493 | to the core @code{with-fluids*} (@pxref{Fluids and Dynamic States}). |
eeadfda1 KR |
2494 | @end defun |
2495 | ||
2496 | ||
2497 | @sp 1 | |
b4fddbbe MV |
2498 | Parameter objects are implemented using fluids (@pxref{Fluids and |
2499 | Dynamic States}), so each dynamic state has it's own parameter | |
2500 | locations. That includes the separate locations when outside any | |
2501 | @code{parameterize} form. When a parameter is created it gets a | |
2502 | separate initial location in each dynamic state, all initialized to | |
2503 | the given @var{init} value. | |
2504 | ||
2505 | As alluded to above, because each thread usually has a separate | |
2506 | dynamic state, each thread has it's own locations behind parameter | |
2507 | objects, and changes in one thread are not visible to any other. When | |
2508 | a new dynamic state or thread is created, the values of parameters in | |
2509 | the originating context are copied, into new locations. | |
eeadfda1 KR |
2510 | |
2511 | SRFI-39 doesn't specify the interaction between parameter objects and | |
2512 | threads, so the threading behaviour described here should be regarded | |
2513 | as Guile-specific. | |
2514 | ||
2515 | ||
4ea9becb KR |
2516 | @node SRFI-55 |
2517 | @subsection SRFI-55 - Requiring Features | |
2518 | @cindex SRFI-55 | |
2519 | ||
2520 | SRFI-55 provides @code{require-extension} which is a portable | |
2521 | mechanism to load selected SRFI modules. This is implemented in the | |
2522 | Guile core, there's no module needed to get SRFI-55 itself. | |
2523 | ||
2524 | @deffn {library syntax} require-extension clause@dots{} | |
2525 | Require each of the given @var{clause} features, throwing an error if | |
2526 | any are unavailable. | |
2527 | ||
2528 | A @var{clause} is of the form @code{(@var{identifier} arg...)}. The | |
2529 | only @var{identifier} currently supported is @code{srfi} and the | |
2530 | arguments are SRFI numbers. For example to get SRFI-1 and SRFI-6, | |
2531 | ||
2532 | @example | |
2533 | (require-extension (srfi 1 6)) | |
2534 | @end example | |
2535 | ||
2536 | @code{require-extension} can only be used at the top-level. | |
2537 | ||
2538 | A Guile-specific program can simply @code{use-modules} to load SRFIs | |
2539 | not already in the core, @code{require-extension} is for programs | |
2540 | designed to be portable to other Scheme implementations. | |
2541 | @end deffn | |
2542 | ||
2543 | ||
8503beb8 KR |
2544 | @node SRFI-60 |
2545 | @subsection SRFI-60 - Integers as Bits | |
2546 | @cindex SRFI-60 | |
2547 | @cindex integers as bits | |
2548 | @cindex bitwise logical | |
2549 | ||
2550 | This SRFI provides various functions for treating integers as bits and | |
2551 | for bitwise manipulations. These functions can be obtained with, | |
2552 | ||
2553 | @example | |
2554 | (use-modules (srfi srfi-60)) | |
2555 | @end example | |
2556 | ||
2557 | Integers are treated as infinite precision twos-complement, the same | |
2558 | as in the core logical functions (@pxref{Bitwise Operations}). And | |
2559 | likewise bit indexes start from 0 for the least significant bit. The | |
2560 | following functions in this SRFI are already in the Guile core, | |
2561 | ||
2562 | @quotation | |
2563 | @code{logand}, | |
2564 | @code{logior}, | |
2565 | @code{logxor}, | |
2566 | @code{lognot}, | |
2567 | @code{logtest}, | |
2568 | @code{logcount}, | |
2569 | @code{integer-length}, | |
2570 | @code{logbit?}, | |
2571 | @code{ash} | |
2572 | @end quotation | |
2573 | ||
2574 | @sp 1 | |
2575 | @defun bitwise-and n1 ... | |
2576 | @defunx bitwise-ior n1 ... | |
2577 | @defunx bitwise-xor n1 ... | |
2578 | @defunx bitwise-not n | |
2579 | @defunx any-bits-set? j k | |
2580 | @defunx bit-set? index n | |
2581 | @defunx arithmetic-shift n count | |
2582 | @defunx bit-field n start end | |
2583 | @defunx bit-count n | |
2584 | Aliases for @code{logand}, @code{logior}, @code{logxor}, | |
2585 | @code{lognot}, @code{logtest}, @code{logbit?}, @code{ash}, | |
2586 | @code{bit-extract} and @code{logcount} respectively. | |
2587 | ||
2588 | Note that the name @code{bit-count} conflicts with @code{bit-count} in | |
2589 | the core (@pxref{Bit Vectors}). | |
2590 | @end defun | |
2591 | ||
2592 | @defun bitwise-if mask n1 n0 | |
2593 | @defunx bitwise-merge mask n1 n0 | |
2594 | Return an integer with bits selected from @var{n1} and @var{n0} | |
2595 | according to @var{mask}. Those bits where @var{mask} has 1s are taken | |
2596 | from @var{n1}, and those where @var{mask} has 0s are taken from | |
2597 | @var{n0}. | |
2598 | ||
2599 | @example | |
2600 | (bitwise-if 3 #b0101 #b1010) @result{} 9 | |
2601 | @end example | |
2602 | @end defun | |
2603 | ||
2604 | @defun log2-binary-factors n | |
2605 | @defunx first-set-bit n | |
2606 | Return a count of how many factors of 2 are present in @var{n}. This | |
2607 | is also the bit index of the lowest 1 bit in @var{n}. If @var{n} is | |
2608 | 0, the return is @math{-1}. | |
2609 | ||
2610 | @example | |
2611 | (log2-binary-factors 6) @result{} 1 | |
2612 | (log2-binary-factors -8) @result{} 3 | |
2613 | @end example | |
2614 | @end defun | |
2615 | ||
2616 | @defun copy-bit index n newbit | |
2617 | Return @var{n} with the bit at @var{index} set according to | |
2618 | @var{newbit}. @var{newbit} should be @code{#t} to set the bit to 1, | |
2619 | or @code{#f} to set it to 0. Bits other than at @var{index} are | |
2620 | unchanged in the return. | |
2621 | ||
2622 | @example | |
2623 | (copy-bit 1 #b0101 #t) @result{} 7 | |
2624 | @end example | |
2625 | @end defun | |
2626 | ||
2627 | @defun copy-bit-field n newbits start end | |
2628 | Return @var{n} with the bits from @var{start} (inclusive) to @var{end} | |
2629 | (exclusive) changed to the value @var{newbits}. | |
2630 | ||
2631 | The least significant bit in @var{newbits} goes to @var{start}, the | |
2632 | next to @math{@var{start}+1}, etc. Anything in @var{newbits} past the | |
2633 | @var{end} given is ignored. | |
2634 | ||
2635 | @example | |
2636 | (copy-bit-field #b10000 #b11 1 3) @result{} #b10110 | |
2637 | @end example | |
2638 | @end defun | |
2639 | ||
2640 | @defun rotate-bit-field n count start end | |
2641 | Return @var{n} with the bit field from @var{start} (inclusive) to | |
2642 | @var{end} (exclusive) rotated upwards by @var{count} bits. | |
2643 | ||
2644 | @var{count} can be positive or negative, and it can be more than the | |
2645 | field width (it'll be reduced modulo the width). | |
2646 | ||
2647 | @example | |
2648 | (rotate-bit-field #b0110 2 1 4) @result{} #b1010 | |
2649 | @end example | |
2650 | @end defun | |
2651 | ||
2652 | @defun reverse-bit-field n start end | |
2653 | Return @var{n} with the bits from @var{start} (inclusive) to @var{end} | |
2654 | (exclusive) reversed. | |
2655 | ||
2656 | @example | |
2657 | (reverse-bit-field #b101001 2 4) @result{} #b100101 | |
2658 | @end example | |
2659 | @end defun | |
2660 | ||
2661 | @defun integer->list n [len] | |
2662 | Return bits from @var{n} in the form of a list of @code{#t} for 1 and | |
2663 | @code{#f} for 0. The least significant @var{len} bits are returned, | |
2664 | and the first list element is the most significant of those bits. If | |
2665 | @var{len} is not given, the default is @code{(integer-length @var{n})} | |
2666 | (@pxref{Bitwise Operations}). | |
2667 | ||
2668 | @example | |
2669 | (integer->list 6) @result{} (#t #t #f) | |
2670 | (integer->list 1 4) @result{} (#f #f #f #t) | |
2671 | @end example | |
2672 | @end defun | |
2673 | ||
2674 | @defun list->integer lst | |
2675 | @defunx booleans->integer bool@dots{} | |
2676 | Return an integer formed bitwise from the given @var{lst} list of | |
2677 | booleans, or for @code{booleans->integer} from the @var{bool} | |
2678 | arguments. | |
2679 | ||
2680 | Each boolean is @code{#t} for a 1 and @code{#f} for a 0. The first | |
2681 | element becomes the most significant bit in the return. | |
2682 | ||
2683 | @example | |
2684 | (list->integer '(#t #f #t #f)) @result{} 10 | |
2685 | @end example | |
2686 | @end defun | |
2687 | ||
2688 | ||
43ed3b69 MV |
2689 | @node SRFI-61 |
2690 | @subsection SRFI-61 - A more general @code{cond} clause | |
2691 | ||
2692 | This SRFI extends RnRS @code{cond} to support test expressions that | |
2693 | return multiple values, as well as arbitrary definitions of test | |
2694 | success. SRFI 61 is implemented in the Guile core; there's no module | |
2695 | needed to get SRFI-61 itself. Extended @code{cond} is documented in | |
2696 | @ref{if cond case,, Simple Conditional Evaluation}. | |
2697 | ||
2698 | ||
12991fed | 2699 | @c srfi-modules.texi ends here |
193239f1 KR |
2700 | |
2701 | @c Local Variables: | |
2702 | @c TeX-master: "guile.texi" | |
2703 | @c End: |