Re: S-expression I/O in Ada

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

"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. (By "octet" here I mean the 
same concept that Ada calls Stream_Elements, other than with a fixed size.)

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

...
>>> 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; it has 
to be explicitly defined.

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

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

                        Randy.