Re: S-expression I/O in Ada

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ayxycml2mo60$.1g3uh1fg6m3r0.dlg@40tude.net...
> On Thu, 12 Aug 2010 15:56:41 -0500, Randy Brukardt wrote:
...
>> Octets don't have a sum, "sum of octets" is meaningless. It's like 
>> talking
>> about the "sum of sand". They're just buckets.
>
> The content of the bucket does have sum. Compare it with the elements an
> integer array. According to the logic since array elements are buckets you
> cannot sum integer elements.

By "bucket" here I mean a semantic-less collection of bits. Integer elements 
can be summed because they are integers. Buckets of bits don't make sense to 
be summed.

>> (By "octet" here I mean the
>> same concept that Ada calls Stream_Elements, other than with a fixed 
>> size.)
>
> 1. This is not the way octets are used in communication applications.

No idea. I use Stream_Elements the way I describe here in *my* applications, 
but YMMV.

> 2. If the idea of opaque container is pushed to its end, octet must have 
> no
> "and", "or", bit extraction operations either. They also presume some way
> octets can be manipulated and interact with other types (like Boolean).

Correct, an octet should have no operations whatsoever. It's just a bucket 
of bits for transport; it needs to be converted to something real to use it, 
explicitly so it is obvious what is going on.

Besides, I don't believe in bit operations groups of bits in the first 
place; they should be restricted to Boolean logic. (Ada 83 got this right, 
IMHO.)

There is of course a certain expediency in copying bad ideas from other 
languages like C; that's whats going on with Ada modular types. But the 
whole thing is a bad idea from the start to the end.

>> And if you do that, you now
>> have a lot more chances for error (such as adding octets that are used to
>> hold character values and not integers).
>
> Yes, when implementing a communication protocol, there is no such things 
> as
> characters or integers, only octets. This is independent on the octet
> operations. Compare it with address arithmetic. You can sum address of a
> task with the address of an employee record. Does it mean that there has 
> to
> be no address arithmetic?

I'm a radical on this, too. There should be no address arithmetic in 
programming languages; leave that to us compiler-writers, we can do a better 
(and much safer) job. Exposing that low-level stuff is a recipe for 
disaster.

(Again, I realize that there are times, mostly in interfaces to low-level 
languages and hardware, where you need such things. But this is totally 
outside of the realm of anything that can be described with sane typing; it 
makes no sense to even try.)

>> Octets are by their nature an
>> untyped bucket with no semantics; there has to be a conversion operation
>> (like "#" above or S'Read in Ada) to some type with semantics for it to 
>> be
>> meaningful.
>
> No, that is impossible, because 1) there is no such conversion in almost
> any case. Other objects are represented by collections of octets
> interlinked in a very complex way. A simple conversion operation is
> absolutely unsuitable abstraction for this. 2) You are talking about an
> interface, (where however there should be no octets visible at all, but
> streams, files etc), I am talking about implementation of such an
> interface. There should be no conversions at any abstraction level.

I don't have any idea of what you are talking about; it makes no sense to me 
at all. As you say, you should never have octets visible in the first place 
above the transport layer. And in that layer, the only thing that makes 
sense is a conversion to a meaningful type (S'Read is just a fancy name for 
Unchecked_Conversion, after all).

 >>>> That's the point: in Ada, type conversions are *not* functions, 
they're a
>>>> built-in gizmo [including some attributed]; by naming them "#" we would
>>>> allow unifying them with functions.
>>>
>>> I would prefer to eliminate them altogether. Conversions are always bad.
>>
>> I strongly disagree. Some things are best modeled with little or no 
>> explicit
>> semantics (such as a raw stream), and you must have conversions to get to
>> real semantics. Indeed, *not* having using conversions in that case is
>> misleading; you're applying improper semantics to the operation.
>
>   type Text_Stream is new Raw_Stream with private;
>
> What is wrong with that?

It's applying misleading semantics to an entity; there can be no stream 
other than a raw stream; even if the stream carries typing information, that 
information has to be converted and interpreted before it can be used.

I don't think this discussion is going anywhere anyway.

                      Randy.