3.1.4 Type Conversions

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.)

This document was generated on December 10, 2012 using texi2html 1.82.