External library functions accessed by the library combinator
as explained in Library combinator may operate on data other
than the list type usually used by avram, such as
floating point numbers and arrays, but a virtual code application must
be able to represent the arguments and results of these functions in
order to use them. As a matter of convention, a data structure
occupying size bytes of contiguous storage on the host machine
appears as a list of length size to a virtual code application,
in which each item corresponds to a byte, and is represented according
to Character Table.
In principle, a virtual code application invoking a library function to operate on a contiguous block of data, such as an IEEE double precision number, for example, would construct a list of eight character representations (one for each byte in a double precision number), and pass this list as an argument to the library function. The virtual machine would transparently convert this representation to the native floating point format, evaluate the function, and convert the result back to a list. In practice, high level language features beyond the scope of this document would insulate the programmer from some of the details on the application side as well.
To save the time of repeatedly converting between the list
representation and the contiguous native binary representation, the
structure referenced by a list pointer contains a value
field which is a void pointer to a block of memory of
unspecified type, and serves as a persistent cache of the value
represented by the list. This field normally should be managed by the
API rather than being accessed directly by client modules, but see the
code in mpfr.c for an example of a situation in which it's
appropriate to break this rule. (Generally these situations involve
library functions operating on non-contiguous data.)