Re: Printing Enum Variable Re: Linux World

[dewar@gnat.com]

In article <36DE58B5.49B@ddre.dk>,
  hm@ddre.dk_nospam wrote:
> When Robert Dewar says so, I must accept that it is so.
> (But maybe the Ada-community would be better served if
> not)

I disagree, any attempt to prescribe the form of external
characters provided by the operating system would be hugely
messy and of no value to users of Ada.

Remember that if you want an Ada 95 compiler that "does
the right thing" in a PC environment for example, you are
actually asking for a non-standard non-conforming Ada
compiler which recognizes PC encodings rather than the
standard Latin-1 encodings.

Note that for most purposes, it does not matter at all
what the external relationships are (you put characters
into your program, and they come out "right"). There are
some exceptions, e.g. identifier encoding, which is why
GNAT provides specific (non-standard) localization options
for additional character sets:

 Latin-2
 Latin-3
 Latin-4
 IBM PC Code page 437 (typical US default)
 IBM PC Code page 850 (Latin-1 style)
 No Upper Half

and also supports multiple encodings for wide characters:

 Hex coding
 Upper-half coding
 Shift JIS
 EUC
 Brackets coding
 UTF-8 coding

If you have problems with code sets, most likely the
problem is one of operating system configuration, rather
than the compiler. The only obligation of a compiler are
the following:

  1) To accept sources with some reasonable representation
     of all required characters (there is NO requirement to
     accept Latin-1 ISO encoded sources, and you would not
     want their to be such a requirement, since it may make
     no sense in some environments, e.g. an IBM mainframe
     compiler can reasonably use extended EBCDIC for
     sources.

  2) To process internal string data according to Latin-1
     interpretation (means little most of the time, since
     these are just character codes, but has meaning in
     connection with the standard string handling packages)

  3) Similar requirements for wide characters

Now if you want to worry about how these characters will
*look* on some external medium, such as an OS window or
a printer, don't look to the compiler! It has no control
over the fonts you select, the printers you buy, the
operating systems options you select etc. If the wrong
characters are coming out, talk to your OS vendor, not
your compiler vendor (well of course the compiler vendor
may well be able to help with useful advice, certainly we
would, but the problem is not in the compiler and is
certainly not a validation issue). Any attempt to make
this a validation issue misunderstands what validation
is all about. Validation is about conformance, NOT about
usability in a given environment. Validation is just one
of many ways of evaluating a compiler for suitability to
a given task.

> Regarding similar common (mis?)conceptions, is it true
> that the current validation still allows a compiler
> to put arbitrary limits on compilable program size?
> (such as to disallow any program bigger than 1 character)
> or to take forever to compile?

Validation has never allowed this, what on earth would make
you think otherwise?

Read AI-325 for Ada 83, or Ada 95 RM

      6  Contain no variations except those explicitly
         permitted by this International Standard, or those
         that are impossible or impractical to avoid given
         the implementation's execution environment.

This has always been intepreted by the validation process
to mean that if a test is rejected for capacity arguments,
the capacity arguments must be pragmatically reasonable. I
cannot recall many instances where this was appealed to,
and certainly none when it was unreasonably appealed to
with examples of the kind you cite.

Robert Dewar
Ada Core Technologies


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own