In writing some signal processing software, I ran across a few
problems with Marshall.  I'd like ideas about how OCAML might
address these.

First, floats are simply written in increasing byte order OCAML
makes no attempt to rearrange based on endianness.  I think byte
order is discovered on configuration when building the system.
Should OCAML swap byte orders on some hardware to try to compen-
sate, or should we make no attempt to record floating point
portably between the major architectures?  The change in byterun/
intern.c and byterun/extern.c to handle byte swapping is fairly
trivial provided we include the config.h

Harder, does anyone have any good ideas besides conversion to
and from lists for marshalling floating arrays between bytecode
and native OCAML programs?  Without this sort of thing, one must
walk structures by hand if there are variant types with floating
arrays.

The reason for all this noise is that marshalling is ostensibly
to provide an external representation for non-code structured
data, but to be thorough, must we not try to be portable?

Ideas?

-- 
Christopher Oliver                     Traverse Internet
Systems Coordinator                    223 Grandview Pkwy, Suite 108
oliver@traverse.net                    Traverse City, Michigan, 49684
let magic f = fun x -> x and more_magic n f = fun x -> f ((n f) x);;