Re: Problem using Ada.Text_IO.Modular_IO

[Georg Bauhaus <see.reply.to@maps.futureapps.de>]

anon wrote:
> Why re-invent the Wheel!!! If we spend all day re-stating that which 
> has been done then nothing new get done that day! 


As Adam is pointing out below---in two paragraphs which I think
are really recommended reading---Unsigned_64 is defined for a
specific programming context. Typically that of interfacing
to 2**N bit addressable hardware, N >= 3.

When a program does not perform any interfacing, but still
uses types from Interfaces, then in a sense its use of type is
close to C's approach to the fundamental type system:
In C, you have fundamental "scalar" types that say,
"at least that many bits, some operations, some behavior at the
bounds, and please look up the rest in the compiler's
documentation".  When Ada allows the programmer to work at a
higher level of type isolation and expressiveness, without loosing
any performance, not having to consult compiler docs,
isn't this a win?

I recall a c.l.ada message from a university teacher of embedded
systems programming (model trains, I think) whose classes had
switched from C to Ada. After that, the students had achieved more
and got better results. The effect was attributed to Ada's
fundamental type system and types defined in terms of the
(abstracted) problem domain.  I.e., not just Interfaces.


> In <32e35e5a-3cae-4fdc-be4a-3ae1e146e9f3@l64g2000hse.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes:

>> Of course, it really doesn't matter which one you use (except,
>> perhaps, to help prevent incorrect type conversions).  The only
>> differences have to do with readability, pedagogy, and helping make
>> your programs self-documenting.  But ever since Ada was designed, the
>> position of the Ada community has been that it's better to avoid using
>> the standard numeric types provided by Ada (Integer, Float) and define
>> your own that explicitly include the numeric range you need.  You seem
>> to be going in the opposite direction, by recommending that this user
>> use a standard type provided by the language rather than defining his
>> own (although the standard type you recommend is certainly better
>> defined than Integer or Float).
>>
>> Another issue is that an implementation doesn't have to provide
>> Interfaces.Unsigned_64.  It should be present on any target processor
>> whose addressable unit is an 8-bit byte or a 16-, 32-, or 64-bit
>> word.  But I've seen processors in the past that use 6-bit characters
>> or 36-bit words, and in those cases, using Unsigned_64 instead of "mod
>> 2**64" will turn a portable program into a nonportable one.  I'll
>> grant that such processors are rare these days.
>>
>>                                  -- Adam
>>
> 

--
Georg Bauhaus
Y A Time Drain http://www.9toX.de