Re: Simple Data Endianness

[Optikos <ZUERCHER_Andreas@outlook.com>]

On Thursday, February 13, 2020 at 9:28:16 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2020-02-13 16:12, Optikos wrote:
> > On Thursday, February 13, 2020 at 5:10:44 AM UTC-6, Dmitry A. Kazakov wrote:
> >> On 2020-02-13 10:42, guijarrockGuijarro wrote:
> >>
> >>> The problem I present today is related to the coexistence between big-endian and little-endian application data.
> >>
> >> How low-level representation aspect might be relevant to application data?
> > 
> > If the exchange of app data between 2 or more computers is word-wise binary instead of byte-wise textual, such as via binary-formatted files or via binary-formatted datagrams/byte-streams as payload of networking protocols.
> 
> And how whatever protocol encoding format is could to "coexist" (?) with 
> another itself (?)
> 
> In any case it has nothing to do with application data as kept in the 
> memory.

Even your facetious example of app-data exchanged in Mayan numerals stored in GIF images needs to be in DRAM for encoding and decoding the app-data to other modules of software elsewhere in the app.  Implying that the app-domain must absolutely keep a single copy of its data without making any other copies of that app data is a strawman.  There will be user-inteface copies of substantially the same app-data.  There will be file-representation copies of substantially the same app-data.  There will be optimized numerical-processing copies of substantially the same app-data.  There will be general intra-app interchange processing of substantially the same app-data.  Anyone who thinks that there should be a single copy (or a Draconianly-minimized quantity of copies) of app-data needs to spend some time studying model-view-controller software architecture a bit more—or better yet MVVM, or better yet still VIPER.  VIPER takes minding-your-own-business regarding each* app-zone's differing needs regarding each* app-zone's copy/representation of the app-data to the Nth degree to achieve a wise separation of concerns and in turn to achieve collocation of reference when that is needed for efficiency in some app-zone that has collocation of reference as its concern.

* broadly categorized into 5 buckets, where each contains multiple/numerous OO class-trees that hand off to each other in disciplined ways:  view (V), presenter (P), interactor (I), entity (E), router (R)
https://cdn-images-1.medium.com/max/2000/1*YBRVqOQw0q1a5g1RFP6REQ.png

> BTW, supposing the exchange protocol happens to be Mayan numerals stored 
> in GIF images. What representation clause we need in Ada for that?

When Ada has Mayan numerals and GIF images as 1st-class citizens in the core language (i.e., not even the standard library), then, yes, Ada would need to have representation clauses for them.  Obviously, this would be a major disincentive to standardizing Mayan numeral and GIF images in the core language.  Perhaps you could submit an AI on an 01 April of some year to see how far the AI gets in the process.