Re: S-expression I/O in Ada

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

On Mon, 09 Aug 2010 09:48:02 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> The implementation or the idea? Would you agree that objects with some
>> properties of modular integers have place in Ada programs which do not
>> interface C?
> 
> No.  I do not like implicit "mod".  But that's the essence of
> modular types.
> 
> If I ran the circus, then this:
> 
>     M : constant := 2**64;
>     type My_Unsigned is range 0..M-1;
>     pragma Assert(My_Unsigned'Size = 64);
> 
>     X : My_Unsigned := ...;
>     Y : My_Unsigned := (X + 1) mod M;
> 
> would be legal, and would not raise any exceptions, even when
> X = M-1.  (And I'd want "(X + 1) mod M" to be implemented
> as a single "add" instruction on a typical 64-bit machine.)

What does "+" above return? Is "mod M" a required part of the notation or
not?

>>> Perhaps they _should_ be unordered, but I won't agree or disagree,
>>> since I think in an ideal world they should be banished.
>>
>> I think they could be fixed.
> 
> How?  And having fixed them, when would you use them?
> That is, when would you prefer them over signed integers?

Ring buffer indexing, flags (by-value sets actually), cryptography,
interfacing, communication.

I think that all these usages require different types of modular types with
different sets of operations. So I would prefer a language extension which
would allow me construction of such types rather than built-in ones, which
satisfy no one. Just one example from a huge list, why "in" is not an
operation?

   if 0 /= (Mode and Alarm) then  -- Isn't it awful?

why am I not allowed to have:

   if Alarm in Mode then

>>> By the way, one defense of modular types I've heard is that
>>> they are used in mathematics.  True.
>>
>>>  But mathematicians do
>>> not use _implicit_ mod.  They say things like "X = Y (mod N)",
>>> which is pronounced "X is congruent to Y (modulo N)".
>>> Congruent, not equal.
>>
>> The mathematical notation (mod N) is untyped. It applies to any natural
>> numbers and what is worse you have to add it at each point of the program
>> you use the type.
> 
> Writing "mod" whenever I want an expression that takes the modulus is
> a GOOD thing.  "+" should always do an add, and nothing else.

Huh, modular "+" *does* add in the ring. Your "+" does not!

> If want to negate the result of "+", I should write "-".

Negative inverse in a ring is not one of integers. They are different
types. It is good and helpful that Ada promotes this difference.

> If want to take the modulus of the result of "+", I should
> write "mod".

That would be a type conversion. Bad thing. But I see no problem with that.
Give me universal integers or equivalent "2 x width" type and you will get
what you want in return:

   function "+" (Left, Right : Modular) return Universal_Integer;
       -- overloads standard +, if that exists

--  function "mod" (Left, Right : Universal_Integer) return Modular;
--      just to remember, it already exists

That's it.

> Look at how unsigned types are used in C.  size_t is a good
> example.  It's used to count up the sizes of things.
> If I have 1000 objects of size 10_000_000, the total
> size is 1000*10_000_000 = 10_000_000_000.  If that
> calculation wraps around on a 32-bit machine, the
> answer is just plain wrong.  I'd rather get Constraint_Error.
> 
> If I interface to C's size_t, and do similar calculations on
> the Ada side, wraparound is equally wrong.

I agree. But it rather means that C is wrong defining size_t modular. On
Ada side it must be Natural_32. Why Ada does not support that? Why is it
impossible to declare 32-bit range 0..2**32-1 without wrapping (=with
overflow check)?

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