Re: Representation clauses for base-64 encoding

[anon@att.net]

With the current Ada Standard there are too many options and that called 
"The Killing and the Death" for any language. There should be only one 
option for the Ada Standard. Either you support all features or no features 
not even the language itself.  

Thou Ada Standard might include a sub-class for those compilers that do 
not follow the complete standard and must use the word "Sub-Ada" when 
referring to its compiler and libraries. And all impractical sections 
must be documented in detail and approved by a non-ARG sub-committee 
appointed by the ARG. But for the most Ada systems that too much work.

An example of a "Sub-Ada" could be where Ada is implemented on a JVM. 
Some might say the "Machine_Code" package is impractical, because
on these systems there are two assembly languages. The first being the 
"J-Code" used by the JVM and the second being the hardware CPU assembly 
which in most cases in unknown to the JVM. Even though Ada does not know 
the hardware the Ada system should know the "J-Code" for the Java version 
it was written for. 

But the "System.RPC" package is another story, because no Java machine 
support the RPC sub-system so the JVM version would have to be approved 
by the Ada sub-committee or no JVM Ada would exist. Unless the RPC 
sub-system is fully emulated for a JVM in Ada software.


In <wcclipwcian.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> Yes, a compiler cannot claim to support annex C (Systems Programming)
>> unless it implements chapter 13 as recommended, so that all the
>> "shoulds" are implemented. But this is only an argument for "probable"
>> portability, since supporting annex C is optional.
>
>Right.
>
>But of course supporting the Ada standard is optional, too.  ;-)
>It's easy to forget that standards don't actually _require_ anybody
>to do anything.  So, unfortunately, the best you can be sure of is
>"probable" portability.
>
>> Out of curiosity, what is the case for JGNAT?
>
>I don't know much about JGNAT.  I think it doesn't support some
>things that are "impossible or impractical" (see AARM-1.1.3(6)),
>given the limitations of the JVM.
>
>- Bob