2 Types🔗ℹ

Generic utilities for constructing data and transforming it from one type to another.

The type constructors and transformers provided by Racket out of the box are type-specific; for instance in order to construct a list, we use cons or list, and for a stream we’d use stream-cons or stream. Likewise, to convert data into a string, we would use symbol->string if the data is a symbol, and number->string if the data is a number. Similarly, converting a number to an integer from a more precise form, or vice versa, typically involves multiple steps and the method varies depending on the number’s type.

This module provides a generic type constructor that constructs a type by referring to a provided instance, and also provides convenient interfaces to perform many common type conversions, while keeping them agnostic to the source type. If mutable and immutable versions of a data type exist, these interfaces will return the immutable version.

See also: Sugar.

2.1 Constructors🔗ℹ

: is a convenience wrapper around make with a more familiar interface, mirroring the cons list constructor in terms of argument order and the constructed result, and handling additional common cases outside the purview of make. In particular, if form is not a generic collection, then the elements are simply cons’d together (if there are two of them) or collected into a list (if there are more).

make! and :! are similar except that they mutate the form rather than construct the new object "functionally."

These constructors are a generic alternative to type-specific constructors like cons, stream-cons, set-add, hash-set, and so on (along with their mutative counterparts), with the caveat that for streams, the construction will not happen lazily since these generic versions are functions rather than macros. For streams, unless you are just prototyping or running tests in a shell, you will want to use stream-cons directly.

2.2 Transformers🔗ℹ

Note that, owing to the stateful nature of the underlying generator, it’s possible that a stream constructed from a generator would continue to provide lazy evaluation but not take up constant memory. On the other hand, a stream to generator conversion should not incur any additional memory overhead.

Another thing to be wary of with a generator to stream conversion is that since the underlying generator is mutable, independent invocations of the generator after the stream has been constructed would affect the sequence represented by the stream, which is likely to result in unexpected behavior. In general it is advisable to manipulate stateful entities such as generators via a single common interface, whether that is, in the present case, the generator itself directly, or the stream representation of it – but not both.

string->symex maps a string to a symex by treating the string as a representation of a symex rather than as a symex itself (which it is, since a string by itself is a valid expression).