Re: strange behaviour of utf-8 files

["G.B." <rm-dash-bau-haus@dash.futureapps.de>]

On 18.11.13 16:25, Dmitry A. Kazakov wrote:
> Compare:
>
> 123 is a literal of Integer, mod 341, Unsigned_16, ... types

Compare

   type My_Int is range 1 .. 10
     with Size => 16;

to

   type My_Int is range 1 .. 10
     with Size => 32;


Now

   type My_Char is range 'A' .. 'Z'
     with size => 31;

to

   type My_Char is range 'A' .. 'Z'
     with size => 15;


And

   type My_Float is digits 6 range 0.0 .. 1_000.0
     with Mode => Round_To_Nearest_Even;

These are representation issues. They direct the compiler
to choose (a) a number of bits and (b) a set of operations.
"+" will be affected by 'Size, though not at the level of
abstract operations.

I guess there is a view that says rounding is a type? So what:

An encoding aspect would just be a means that allows programmers
to say what they mean. It may not be as useful as -gnatW*, it may even
be confusing, but it may finally kick the * of compiler makers and
project leads, and make them sort out this encoding nonsense once
and forever. Without rhetoric. And *then* they can say that
specifying aspects is fundamentally wrong.

After all, this is about interpreting a bit pattern at compile
time, and supplying information about the bits explicitly should
help. It should help fixing C's underlying char* issues, too.

Even when using 7bit ASCII, there is *no* information in the
source that explicitly states what is meant in a given ASCII
String literal. So, saying that ASCII works is just accidentally
right. A good argument in a C camp.