Re: S-expression I/O in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 12 Aug 2010 15:56:41 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1spow9sibnv6l.ci558lff75c8$.dlg@40tude.net...
>> On Wed, 11 Aug 2010 18:18:48 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:iv3qwjogornz$.1s8kq0yfl2wxl.dlg@40tude.net...
>>> ...
>>>> Conversion mess is what we already have right now. The point is that "+"
>>>> is
>>>> well-defined and meaningful for octets, but it is not closed in there. 
>>>> Why
>>>>
>>>>   function "**" (Left : T; Right : Natural) return T;
>>>>   function S'Pos(Arg : S'Base) return universal_integer;
>>>>   ...
>>>>
>>>> are OK and "+" is not?
>>>
>>> The first has the same operand and result type (the power operand is
>>> something else and not really part of the operator IMHO).
>>
>> What is the difference between "**" and "+"? It must be a language one,
>> because semantically sum of octets is not an octet.
> 
> 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 "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.

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).

>>> The second is the
>>> long winded name for a conversion operator - it implies no semantic change.
>>> I'm arguing that operations like S'Pos would be better having a common name
>>> like "#" rather than a host of specialized names.
>>
>> Huh, and these must be a type conversions too:
>>
>>   function S'Exponent (X : T) return universal_integer;
>>   S'Length
>>   A'Length (N)
>>   ...
> 
> Nope, these have semantics. Of course, the boundary is a gray area.

? semantics = meaning. Why do we need things without meaning = meaningless
things?

>>>> 1. What is this else?
>>>
>>> Huh? This doesn't parse.
>>
>> The above looks like math to me. You take octet arguments and compute some
>> results using arithmetic operations.
> 
> The octets are converted to some other type that has math. There is no 
> built-in relationship between the octet and the type with the math;

Built-in = language defined? But Ada does not define Octet.

> it has to be explicitly defined.

Yes, any operation has to be defined explicitly if not inherited.

>> I see. No, that is a wrong way IMO. The right one is interfaces. If you
>> want S be like T, derive S from T. If you don't like the implementation of
>> T, inherit only the interface of. You should never have a need in explicit
>> type conversions in a properly designed program.
> 
> That way lies madness. You would have to give types properties that they 
> have no reason to have (like "sum of octets").

The semantics is to be defined by the programmer.

> 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?

> 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.

>>> 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?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de