Re: Does Ada support endiannes?

[csampson@inetworld.net (Charles H. Sampson)]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

> On Tue, 13 Dec 2011 21:19:07 -0800, Charles H. Sampson wrote:
> 
> > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> > 
> >> No. The Ada's design goal was to allow the programmer to describe the
> >> semantics the data types involved and to program in that terms.
> >> Representation clauses rather defeat that idea than support it. The number
> >> read from the wire must look and feel as a number rather than some messy
> >> record, which cannot be a numeric parameter of a generic, has no 'Image, no
> >> meaningful literals etc...
> > 
> >      I think I see the place where we have the greatest disagreement in
> > concept.  To me, in general, data coming "over a wire" are just a stream
> > of bits until we have interpreted them and found out what they mean.
> 
> Right, I prefer typed approaches over untyped ones. This is BTW why I
> prefer Ada over other languages.
> 
> Stream of bits is a transport layer, at best, to be hidden under higher
> protocol layers, spilling properly typed objects to the clients. No
> conversions. One advantage of this approach is that the transport being
> properly encapsulated could be easily replaced.

     Well, yes.  You do definitely want to encapsulate all this stuff.
Even though the ugly stuff is hidden to from the clients, I still want
to make the ugly stuff as pretty and understandable as possible.

> >      At that requires a bit more writing than your approach, Dmitry, but
> > that's o. k. with me.  The design of Ada was permitted to require
> > "extra" writing for the purpose of clarity of code.
> 
> I think the problem here is not the volume of the code, but an untyped
> nature of it.

     My code gets "typed" as soon as possible, as soon as I can
recognize what its type is supposed to be.  The reason I wrote _typed_
in quotes is that a stream of bits, where I start, is typed:

   type Bit is range 0 .. 1;
   for Bit'Size use 1;
   type Bit_Stream is array (Positive range <>) of Bit;
   pragma Pack (Bit_Stream);

> Note that if the native and remote objects were distinct types (not
> subtypes), you would not be able to have them as views of the *same*
> object. Thus you would have to convert the remote object to a native one.
> But once you had the latter you would not need the former anymore. The next
> step is just to get rid of it. Why anybody (a client) should see it at all?
> That is my approach.

     The only time I need two views of an object when I need to access
its components, such as when constructing the object or accessing its
components to, for example, construct some other object from them.  I
absolutely agree that you should get numeric values into a proper native
type as soon as possible.  This conversion between native and non-native
type should be confined to IO time.

     Sometime the time between the IO and the conversion is longer than
you might hope, at least on the input side.  Referring again to the last
system I worked on, we often had to read part of the input to determine
the length of the incoming bit string, then read the rest in, and then
begin the checking to determine exactly what we had.

> As a by-product you get a highly portable code as Gautier pointed out in
> another response.

     I don't understand this claim of highly portable code without using
a rep spec.  A rep spec is necessary to insure proper allocation of a
record's components.  Your earlier questioning of the order of the
components in my definition of the type Single_Precision leads me to
think that you aren't aware that there is no link between the lexical
order of a record type definition and the layout of its components in
memory.  In other words, a compiler is free to "move components around".
They usually do this to achieve an efficient memory layout but they
could do in just on a whim of the compiler writer.

> IMO, representation clauses are evil and not Ada (TM).

     IMO, representation clauses are a blessing that allows me to take
full control of the representation when I need to.  That's one of many
reasons why I prefer Ada to any other language I know, to the point that
I refuse to program in any other language.  (Being past retirement age
has certain benefits.)

     By the way, Dmitry, I hope you understand that by carrying on this
dialog I don't intend to imply that you're a idiot who has no idea what
he's doing.  That's obviously not true.  All I'm trying to do is lead
you to enlightenment by exposing you to my clearly superior ideas.  :-)

                        Charlie
-- 
[A certain TV newsreader] had a role to play: presenter of the Other
Side of the Argument, to whom fair-minded people were obligated to
pay heed, no matter what nonsense he spouted.
Charlie Pierce, Idiot America