Re: Michel's comments on interchange representation
John Pryce wrote:
> So it seems you are suggesting
> - Make the main text in §14.4 closer to Ned's wording in C6.2.
> - Don't try to remove the portability difficulty, but make it
> (as you say below) "standard".
Yes. But I do share Dima's concern that we should address true
portability at the file or stream level. There is however another
issue at that level, and that is how individual objects are aggregated.
Assuming a byte stream model (which is pretty universal nowadays), are
they simply concatenated, or is there some additional structure? This
goes way beyond P1788. The point however is that since there is almost
always a need for extra tagging to make exported information importable,
issues such as Endianness can be addressed explicitly, as well as other
details such as which formats and types are stored, what padding and
alignment rules are followed, etc. (think of COBOL's Data Division).
This is the reason why I favour a representation consisting of an
ordered triple of standard datatypes. Everybody know how to deal with
this, including conventions for conveying Endianness information --
even if there at this point no universal rules that everybody follows.
For example, some headers are carefully structured so that they include
a 16-bit field known to hold a small (<256) integer, from which it is
easy to recover ordinary (non-messed-up) Endianness. Or there could be
agreement to encode fields in network byte order, for transmission: this
would be the most straightforward way to achieve Dima's goal, but without
explicitly burdening 1788 with it.
What we could do is add a recommended export function that generates the
floating-point components in network byte order. I don't want to make it
mandatory, because network byte order is well-defined only for int16 and
int32 (for IP and TCP headers); there is still no *standard* way to deal
with 64-bit objects, never mind floating-point.
Dima wondered what John and I meant by "standard portability issues".
I hope that the above makes it clear.
Now, on decoration encoding:
> Now 0 through 4 has the advantage of being simple and natural. I was rather
> attracted to Dmitry's "multiply by 32" (or shift 5 bits left) because of his
> argument "If an implementer wishes to invent new decorations in between the
> existing ones, this lets them do it easily".
That is an interesting argument, given that there is a natural ordering of
the decorations.
> One could consider a compromise: say shift 3 bits left (or 2, or 4).
Ok, how about:
ill 0
trv 4
def 8
dac 12
com 16
with a remark "This encoding permits future refinement without
disturbing the natural propagation order of the decorations."
Michel.
P.S. Dima sent me privately some correspondence on this issue, which I'm
about to read -- but I wanted to reply promptly because it's already
getting late in Europe...
---Sent: 2014-06-19 14:46:38 UTC