This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.
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