On 17 Sep 2004, at 22:33, Alex Shinn wrote:

> 'network is equivalent to 'big-endian.  The separate procedures are
> provided as shorthand for when you want to write code portable across
> different endians, and also to allow for a faster implementation on
> big-endian machines.  This is biased in favor of big-endian machines;
> an alternative would be to have three sets of procedures with no
> optional argument:
>
>   read-<int>  ; native
>   read-be-<int> or read-network-<int>
>   read-le-<int>

a) Presumably those would be slightly faster implementations (with
read-<int> being one or other of read-be-<int> or read-le-<int>).

b) Given some of the other discussion on the list (see bear's comments
on the ubiquity of the Internet), I wonder if it is optimal to have 3
ways to do it.  The reasoning is to *strongly* encourage people to
write portable, network aware, code.

The first approach would be to provide *only* read-be-<int> and
read-le-<int>, possibly named read-net-<int> and read-swapped-<int>
(the latter open to a better name).  Then people could choose to output
their data in swapped form if it was more native, but they could
transfer their code and data to another system portably.  But more
likely people would just use the (more portable) net form (saves
typing, too!).

The second approach would be to provide read-<int> and read-net-<int>,
where the read-<int> does the local thing, and read-net-<int> does the
portable (B.E.) thing.  This has the advantage of providing faster
implementation for storing local data, but has the disadvantage that
data files are no longer portable unless the -net- versions are used.

I prefer the first approach, but I prefer both to having 3 versions.  I
want to encourage people to produce portable applications.

../Dave