ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

This if statement exactly, seems to raise
"ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782"(No indication of line, so I can't know more).
What does this exception means ? You can see there's no string type variable to be accessed, here.
CHAINE is of UNBOUNDED_STRING type. LA_PILE is a stack of characters, EMPILER means "putting on the stack's top" in french.

if IS_BASIC(ELEMENT(CHAINE,IND)) then
   EMPILER(LA_PILE,ELEMENT(CHAINE,IND));
else DELETE(CHAINE, IND,IND);
end if;

It's enclosed in:
for Ind in 1..Length(CHAINE) loop
        begin
            if IS_BASIC(ELEMENT(CHAINE,IND)) then
                    EMPILER(LA_PILE,ELEMENT(CHAINE,IND));
            else DELETE(CHAINE, IND,IND);
            end if;
         end;
end loop;

Thanks

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Niklas Holsti]

On 18-01-15 03:18 , Mehdi Saada wrote:
> This if statement exactly, seems to raise
> "ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782"(No indication of line, so I can't know more).
> What does this exception means ?

That you have tried to access a non-existent element of some kind of 
string (Bounded or Unbounded). Note that Ada.Strings.Bounded and 
Ada.Strings.Unbounded are both children of Ada.Strings, where this 
exception is declared, and both use this exception.

> You can see there's no string type variable to be accessed, here.
> CHAINE is of UNBOUNDED_STRING type.
> LA_PILE is a stack of characters,
> EMPILER means "putting on the stack's top" in french.
>
> if IS_BASIC(ELEMENT(CHAINE,IND)) then

The exception probably comes from the above call of ELEMENT.

>    EMPILER(LA_PILE,ELEMENT(CHAINE,IND));
> else DELETE(CHAINE, IND,IND);
> end if;
>
> It's enclosed in:
> for Ind in 1..Length(CHAINE) loop

Note that the iteration range, 1 .. Length(CHAINE), is computed here 
using the value of CHAINE at the *start* of the loop, and is not 
recomputed during the execution of the loop.

>         begin
>             if IS_BASIC(ELEMENT(CHAINE,IND)) then
>                     EMPILER(LA_PILE,ELEMENT(CHAINE,IND));
>             else DELETE(CHAINE, IND,IND);

This DELETE shortens CHAINE. If it occurs one or more times during the 
iteration of the loop, before the last iteration of the loop, then at 
some later iteration the index Ind will be larger than the (new) 
Length(CHAINE), and the exception results.

>             end if;
>          end;
> end loop;

To fix this error, you must make the loop recompute Length(CHAINE) when 
needed, for example in this way:

    for Ind in 1 .. Length(CHAINE) loop

       exit when Ind > Length(CHAINE);

       if IS_BASIC ...
          ...
       end if;

    end loop;

However, I would write it like this, to avoid the confusion of a double 
check of Length(CHAINE):

    Ind : Positive := 1;
    ...

    while Ind <= Length(CHAINE) loop

       if IS_BASIC ...
          ...
       end if;

       Ind := Ind + 1;

    end loop;

Note that in the "while" loop, the condition (Ind <= Length(CHAINE)) is 
evaluated on every loop iteration. In a "for" loop, the index range is 
evaluated once, at the start of the loop.

However, I suspect that there is a deeper error in your loop, related to 
the DELETE. Consider what happens if CHAINE is, say, "ABCDEFG", and the 
DELETE occurs for the first time when Ind = 3, at CHAINE(Ind) = 'C'. 
When you DELETE(CHAINE, 3, 3), CHAINE becomes "ABDEFG". On the next loop 
iteration, Ind = 4, which means the loop checks CHAINE(4) = 'E'. The 
letter 'D', which used to be CHAINE(4) but is now CHAINE(3), is not checked.

Do you really need to DELETE in the loop? If you do, then you must take 
into account that DELETE renumbers the elements of CHAINE after the 
deleted character.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 15/01/2018 02:18, Mehdi Saada wrote:
> This if statement exactly, seems to raise
> "ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782"(No indication of line, so I can't know more).

There is a list of funny numbers following the exception message. Pass 
that list to

    addr2line --exe=<program-name> <funny-numbers>

That will give you the stack trace.

> What does this exception means ? You can see there's no string type variable to be accessed, here.
> CHAINE is of UNBOUNDED_STRING type. LA_PILE is a stack of characters, EMPILER means "putting on the stack's top" in french.
> 
> if IS_BASIC(ELEMENT(CHAINE,IND)) then
>     EMPILER(LA_PILE,ELEMENT(CHAINE,IND));
> else DELETE(CHAINE, IND,IND);
> end if;
> 
> It's enclosed in:
> for Ind in 1..Length(CHAINE) loop
>          begin
>              if IS_BASIC(ELEMENT(CHAINE,IND)) then
>                      EMPILER(LA_PILE,ELEMENT(CHAINE,IND));
>              else DELETE(CHAINE, IND,IND);
>              end if;
>           end;
> end loop;

When deleting elements of a list by position the loop must run positions 
in reverse:

    for Ind in reverse 1 .. Length (CHAINE) loop
       ...
       delete at Ind
       ...
    end loop;

That will keep the positions straight. Position /= index, BTW.

However, deleting characters from a string almost never has sense. You 
probably should reconsider the algorithm.

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> There is a list of funny numbers following the exception message. Pass
> that list to
>
>    addr2line --exe=<program-name> <funny-numbers>
>
> That will give you the stack trace.

You need to build with -g (debug info) and -bargs -E (-Es?) for this to
work well.

If you're on a Mac, you'd see something like (this is from a demo
program of mine)

   $ ./raiser

   Execution of ./raiser terminated by unhandled exception
   raised PROGRAM_ERROR : raiser.adb:3 explicit raise
   Load address: 0x10cb10000
   Call stack traceback locations:
   0x10cb11163 0x10cb11104

and you get the traceback by

   $ atos -o raiser -l 0x10cb10000 0x10cb11163 0x10cb11104
   _ada_raiser (in raiser) (raiser.adb:3)
   main (in raiser) (b~raiser.adb:158)

where the -l part is the Load address - programs are loaded at random
addresses to defeat some hacking vulnerabilities.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

That's an awful lot of things at once x_x, but thanks. So in linux I have to go past the "./doinstall" script, right... Never used specific compilation option for anything until now.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

That's an awful lot of things at once x_x, but thanks. So in linux I have to go past the "./doinstall" script, right... Never used specific compilation option for anything until now.

> When deleting elements of a list by position the loop must run positions 
>in reverse: 
>[...]
>That will keep the positions straight. Position /= index, BTW. 
>However, deleting characters from a string almost never has sense. You 
>probably should reconsider the algorithm.

Ah ? Why so ? And how come position =/ index ? "IND" is the same, isn't ? Performance consideration ? But fine, I'll do without.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 15/01/2018 13:00, Mehdi Saada wrote:

>> When deleting elements of a list by position the loop must run positions
>> in reverse:
>> [...]
>> That will keep the positions straight. Position /= index, BTW.
>> However, deleting characters from a string almost never has sense. You
>> probably should reconsider the algorithm.
> 
> Ah ? Why so ?

An empiric fact.

> And how come position =/ index ? "IND" is the same, isn't ?

Index can start at any number and for a user-defined string type it 
might be any discrete type, e.g. not a number.

When you use 1..X'Length that is position, When you use X'Range or 
X'First..X'Last that is index.

You cannot delete the element at an index, that would make the array 
non-contiguous. You can do it at a position, which makes indices of the 
elements slide.

Note that in Ada X'Length is of universal integer for all arrays. It is 
silently converted to Integer which gives a false impression of being an 
"index".

P.S. Unbounded and fixed-length strings are not properly designed due to 
language limitations, so Length (X) has the result of a wrong type.

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Shark8]

On Monday, January 15, 2018 at 5:00:21 AM UTC-7, Mehdi Saada wrote:
> That's an awful lot of things at once x_x, but thanks. So in linux I have to go past the "./doinstall" script, right... Never used specific compilation option for anything until now.
> 
> > When deleting elements of a list by position the loop must run positions 
> >in reverse: 
> >[...]
> >That will keep the positions straight. Position /= index, BTW. 
> >However, deleting characters from a string almost never has sense. You 
> >probably should reconsider the algorithm.
> 
> Ah ? Why so ? And how come position =/ index ? "IND" is the same, isn't ? Performance consideration ? But fine, I'll do without.

The reason position isn't index can be simply illustrated with the following array:
  Example : Array( 11..15 ) of Boolean := (True, False, False, True);

In the above, position #1 is True, #2 & #3 are False, and #4 is True.
HOWEVER, position #1 is index 11, #2 is index 12, etc.
(There's also Offset, which is actually why C programmers seem to be enamored with 0-based indexing; but it only shows they conflate index, position, and offset.)

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> That's an awful lot of things at once x_x, but thanks. So in linux I
> have to go past the "./doinstall" script, right... Never used specific
> compilation option for anything until now.

I don't understand what you mean by 'go past the "./doinstall"
script'. Once you've installed the compiler, you use it to compile your
code in the way (with the switches) you want.

If you're building from the command line with gnatmake or gprbuild, say

   $ gnatmake hello.adb -g -bargs -E

(you might add '-f' the first time, to force a rebuild with the new
switches).

Somewhat more complicated with GPS: once your project is loaded, edit
the project properties panel, called up by menu Project > Properties:

in Switches > Builder, check 'Debug information'
in Switches > Binder, check 'Store call stack in exceptions'

& save, then rebuild (Build > Project > Build all).

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

Ah, sorry I understood "compiling the compiler with debugging option". Fine then.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

I got that:
=> addr2line \--exe=ts_pile 0x4098f8 0x4031ae 0x402e0d 0x7efbf78582af 0x40>
??:?
/home/mehdi/essai/TD-TP10/ts_pile.adb:48
/home/mehdi/essai/TD-TP10/b~ts_pile.adb:256
??:0
??:?
??:0

ts_pile.adb:48 is what's between "if" and "then" of:
if IS_LETTER (TO_BASIC( TO_LOWER( ELEMENT( CHAINE,IND)))) then
   EMPILER(LA_PILE,ELEMENT(CHAINE,IND));
   APPEND(CHAINE, ELEMENT(LIGNE,IND));
end if;

The other reference is:
Ensure_Reference : aliased System.Address := Ada_Main_Program_Name'Address;

in:
"function main
     (argc : Integer;
      argv : System.Address;
      envp : System.Address)
      return Integer
   is
      procedure Initialize (Addr : System.Address);
      pragma Import (C, Initialize, "__gnat_initialize");

      procedure Finalize;
      pragma Import (C, Finalize, "__gnat_finalize");
      SEH : aliased array (1 .. 2) of Integer;

      Ensure_Reference : aliased System.Address := Ada_Main_Program_Name'Address;
      pragma Volatile (Ensure_Reference);
" then followed by the function body.

... Now I know what lies behind the apparent simplicity of apparently simple program. Damn !

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

I know (and saw) others mistakes, but that's for later. What's wrong with this "if" line ?

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> I know (and saw) others mistakes, but that's for later. What's wrong
> with this "if" line ?

Your original problem was with

   for Ind in 1..Length(CHAINE) loop
           begin
               if IS_BASIC(ELEMENT(CHAINE,IND)) then
                       EMPILER(LA_PILE,ELEMENT(CHAINE,IND));
               else DELETE(CHAINE, IND,IND);
               end if;
            end;
   end loop;

So suppose Length(CHAINE) started at 10; we're looping from 1 .. 10.

Now suppose you execute the DELETE. That means that now Length(CHAINE)
is 9, *but* you are still looping from 1 .. 10; so that when IND gets to
10 (the loop range doesn't alter), ELEMENT(CHAINE,IND) is trying to
access an element which doesn't exist.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Anh Vo]

On Monday, January 15, 2018 at 12:29:41 AM UTC-8, Dmitry A. Kazakov wrote:
> On 15/01/2018 02:18, Mehdi Saada wrote:
> > This if statement exactly, seems to raise
> > "ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782"(No indication of line, so I can't know more).
> 
> There is a list of funny numbers following the exception message. Pass 
> that list to
> 
>     addr2line --exe=<program-name> <funny-numbers>
> 
> That will give you the stack trace.
 
It is even better to use GNAT addition to print out full stack trace as shown in the snippet.

-- ...

exception

when Err : others =>

  Text_Io.Put_Line ("Houston we have a problem: " &
                                    Exceptions.Exception_Information (Err));
  Text_Io.Put_Line ("Traceback => " & GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
end [Ada Unit Name];

Anh Vo

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 2018-01-15 18:22, Anh Vo wrote:
> On Monday, January 15, 2018 at 12:29:41 AM UTC-8, Dmitry A. Kazakov wrote:
>> On 15/01/2018 02:18, Mehdi Saada wrote:
>>> This if statement exactly, seems to raise
>>> "ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782"(No indication of line, so I can't know more).
>>
>> There is a list of funny numbers following the exception message. Pass
>> that list to
>>
>>      addr2line --exe=<program-name> <funny-numbers>
>>
>> That will give you the stack trace.
>   
> It is even better to use GNAT addition to print out full stack trace as shown in the snippet.
> 
> -- ...
> 
> exception
> 
> when Err : others =>
> 
>    Text_Io.Put_Line ("Houston we have a problem: " &
>                                      Exceptions.Exception_Information (Err));
>    Text_Io.Put_Line ("Traceback => " & GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
> end [Ada Unit Name];

Even better to make AdaCore make this the default behavior when dealing 
with unhandled exception. However considering that it took 20 years or 
so to stop disabling integer overflow checks by default...

P.S. When GPS is running with the switch --server=<port> one can make it 
open the window with the source code at the error line! (:-))

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Anh Vo]

On Monday, January 15, 2018 at 9:48:12 AM UTC-8, Dmitry A. Kazakov wrote:
> On 2018-01-15 18:22, Anh Vo wrote:
> > On Monday, January 15, 2018 at 12:29:41 AM UTC-8, Dmitry A. Kazakov wrote:
> >> On 15/01/2018 02:18, Mehdi Saada wrote:
> >>> This if statement exactly, seems to raise
> >>> "ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782"(No indication of line, so I can't know more).
> >>
> >> There is a list of funny numbers following the exception message. Pass
> >> that list to
> >>
> >>      addr2line --exe=<program-name> <funny-numbers>
> >>
> >> That will give you the stack trace.
> >   
> > It is even better to use GNAT addition to print out full stack trace as shown in the snippet.
> > 
> > -- ...
> > 
> > exception
> > 
> > when Err : others =>
> > 
> >    Text_Io.Put_Line ("Houston we have a problem: " &
> >                                      Exceptions.Exception_Information (Err));
> >    Text_Io.Put_Line ("Traceback => " & GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
> > end [Ada Unit Name];
> 
> Even better to make AdaCore make this the default behavior when dealing 
> with unhandled exception. >>

At least for me, a debugger is never needed. I consider it a tremendous improvement.

> with unhandled exception. However considering that it took 20 years or 
> so to stop disabling integer overflow checks by default...

It was that long. It is late still better than never :-).  If it was me, I would do it in a day.

Anh Vo

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Brian Drummond]

On Mon, 15 Jan 2018 09:22:34 -0800, Anh Vo wrote:

> On Monday, January 15, 2018 at 12:29:41 AM UTC-8, Dmitry A. Kazakov
>> 
>>     addr2line --exe=<program-name> <funny-numbers>
>> 
>> That will give you the stack trace.
>  
> It is even better to use GNAT addition to print out full stack trace as
> shown in the snippet.
> 
> -- ...
> 
> exception
> 
> when Err : others =>
> 
>   Text_Io.Put_Line ("Houston we have a problem: " &
>                                     Exceptions.Exception_Information
>                                     (Err));
>   Text_Io.Put_Line ("Traceback => " &
>   GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
> end [Ada Unit Name];

This has some issues with (FSF) Gnat 6.3 (at least on Debian Stretch).
I asked about this on the Gnoga list, still working through the issues.

(1) It just prints out the same funny numbers, with capital letters in 
the hex part.

(2) Feeding the funny numbers to addr2line just gives a bunch of question 
marks.

The culprit appears to be something to do with Position Independent 
Executables, and Address Space Randomization, which appear to have broken 
a few things. 

Adding "-no-pie" (NOT "-Wl,-no_pie") to the Linker switches changes the 
funny numbers, such that addr2line can now parse them, fixing (2).

However neither this nor explicitly linking libreadline (adding 
"-lreadline" to teh linker options fixes (1). I have a feeling that when 
(2) broke, a quick fix was added to GNAT.Traceback.Symbolic to "fix" (1).

(checking the RTS source I see a comment...
--  This is the default implementation for platforms where the full 
capability
--  is not supported. It returns tracebacks as lists of hexadecimal 
addresses
--  of the form "0x...".

So, apparently not provided in recent-ish FSF Gnat compilers ... if it 
ever was.

-- Brian

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Anh Vo]

On Tuesday, January 16, 2018 at 8:06:33 AM UTC-8, Brian Drummond wrote:
> On Mon, 15 Jan 2018 09:22:34 -0800, Anh Vo wrote:
> 
> > On Monday, January 15, 2018 at 12:29:41 AM UTC-8, Dmitry A. Kazakov
> >> 
> >>     addr2line --exe=<program-name> <funny-numbers>
> >> 
> >> That will give you the stack trace.
> >  
> > It is even better to use GNAT addition to print out full stack trace as
> > shown in the snippet.
> > 
> > -- ...
> > 
> > exception
> > 
> > when Err : others =>
> > 
> >   Text_Io.Put_Line ("Houston we have a problem: " &
> >                                     Exceptions.Exception_Information
> >                                     (Err));
> >   Text_Io.Put_Line ("Traceback => " &
> >   GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
> > end [Ada Unit Name];
> 
> This has some issues with (FSF) Gnat 6.3 (at least on Debian Stretch).
> I asked about this on the Gnoga list, still working through the issues.
> 
> (1) It just prints out the same funny numbers, with capital letters in 
> the hex part.
> 
> (2) Feeding the funny numbers to addr2line just gives a bunch of question 
> marks.
> 
> The culprit appears to be something to do with Position Independent 
> Executables, and Address Space Randomization, which appear to have broken 
> a few things. 
> 
> Adding "-no-pie" (NOT "-Wl,-no_pie") to the Linker switches changes the 
> funny numbers, such that addr2line can now parse them, fixing (2).
> 
> However neither this nor explicitly linking libreadline (adding 
> "-lreadline" to teh linker options fixes (1). I have a feeling that when 
> (2) broke, a quick fix was added to GNAT.Traceback.Symbolic to "fix" (1).
> 
> (checking the RTS source I see a comment...
> --  This is the default implementation for platforms where the full 
> capability
> --  is not supported. It returns tracebacks as lists of hexadecimal 
> addresses
> --  of the form "0x...".
> 
> So, apparently not provided in recent-ish FSF Gnat compilers ... if it 
> ever was.

I trusted that switch -g passed during compilation, -E passed during binding and -g passed during linking.

Anh Vo

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> This if statement exactly, seems to raise "ADA.STRINGS.INDEX_ERROR :
> a-strunb.adb:782"(No indication of line, so I can't know more).

That would be at line 782 of a-strunb.adb (the body of package
Ada.Srings.Unbounded; I don't know why GNAT still uses the krunched form
of file names, which was designed to fit DOS 8.3 file name limitations).

   function Element
     (Source : Unbounded_String;
      Index  : Positive) return Character
   is
      SR : constant Shared_String_Access := Source.Reference;
   begin
      if Index <= SR.Last then
         return SR.Data (Index);
      else
         raise Index_Error;            <<<<<<< line 782
      end if;
   end Element;

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

I succeeded: in the end, I wrote that:
for Ind in reverse 1..Length(LIGNE) loop
         C1 := TO_BASIC( TO_LOWER( ELEMENT( LIGNE,IND )));
         if IS_LETTER(C1) then
            EMPILER(LA_PILE,C1);
            APPEND(CHAINE,C1);
         end if;
end loop;

It's way cleaner. Ah, the joy of succeeding when you know it means a progress in your self-imposed personal objectives. But I would like to know what was intimately wrong with the precedent "if" condition.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Niklas Holsti]

On 18-01-15 18:06 , Mehdi Saada wrote:
> I succeeded: in the end, I wrote that:
> for Ind in reverse 1..Length(LIGNE) loop
>          C1 := TO_BASIC( TO_LOWER( ELEMENT( LIGNE,IND )));
>          if IS_LETTER(C1) then
>             EMPILER(LA_PILE,C1);
>             APPEND(CHAINE,C1);
>          end if;
> end loop;

Note that this loop will stack up (EMPILER) the elements of LIGNE in 
*reverse order* compared to your first loop, "for Ind in 1 .. 
Length(LIGNE)".

This reverse order may or may not be correct for your problem. But 
usually the order of the elements in a stack *is* important.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

But what might people need to use the FSF version instead of Adacore's anyway ?

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Jacob Sparre Andersen]

Mehdi Saada <00120260a@gmail.com> writes:

> But what might people need to use the FSF version instead of Adacore's
> anyway?

Some people may not want to release their executables under the Gnu GPL.

Greetings,

Jacob
-- 
"There's a lot of information that was in the programmer's head
 when they wrote the code that isn't reflected in that code"

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

idiotic me... forgot that. Feels good to live outside real world ;-)
I haven't really understood the thing about me conflating index and position. Where exactly in the piece of code I shared, did I mixed the two ?
I may err elsewhere, if I don't get it now. 

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

Can I write
      SO_size : constant Length_Range := String_Object'Length;
using a renaming statement without significantly more characters ?
I don't think so, but I try to use to use renaming as much possible, it's so elegant...

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 17/01/2018 16:45, Mehdi Saada wrote:
> Can I write
>        SO_size : constant Length_Range := String_Object'Length;
> using a renaming statement without significantly more characters ?

What is Length_Range, an integer subtype?

Remember position vs. index:

    Length : constant Integer := Object'Length;

    First  : constant Index_Type := Object'First;
    Last   : constant Index_Type := Object'Last;

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

> Remember position vs. index:
>     Length : constant Integer := Object'Length;
>     First  : constant Index_Type := Object'First;
>     Last   : constant Index_Type := Object'Last;

Yeah, an Integer subtype. Ah, always something I forget to precise explicitely.
I saw it goes along well with a constant declaration, but I wanted a renaming declaration...

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 17/01/2018 23:50, Mehdi Saada wrote:
>> Remember position vs. index:
>>      Length : constant Integer := Object'Length;
>>      First  : constant Index_Type := Object'First;
>>      Last   : constant Index_Type := Object'Last;
> 
> Yeah, an Integer subtype. Ah, always something I forget to precise explicitely.
> I saw it goes along well with a constant declaration, but I wanted a renaming declaration...

You can rename result of a function too. (It does make much sense in the 
case of scalar values returned by value).

However you cannot rename a non-object. A subtle distinction, but it is 
there. That would prevent renaming of an attribute Object'Length which 
is not an object for whatever strange reason. Attributes have a long 
history of being queer. E.g. "abc"'Length is still illegal, AFAIK. In 
Ada attributes are not considered operations as they should.

A discriminant of some object can be renamed, no problem. So

    type Object_Type (Length : Natural) is ...;
    Object : Object_Type (10);
    Length : Integer renames Object.Length; -- This is OK, 10

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> In Ada attributes are not considered operations as they should.

In spite of the way some attributes can be overridden by operations
(e.g. 'Read).

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 18/01/2018 12:14, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> In Ada attributes are not considered operations as they should.
> 
> In spite of the way some attributes can be overridden by operations
> (e.g. 'Read).

Yes. It should rather have been an operator-syntax with a 
straightforward sugar:

    function "'Image" (X : Integer) return String;

    X'Image <=> "'Image" (X)

And of course primitive for tagged types.

P.S. Falls into the categories "not ugly enough" and "too simple" to 
adopt... (:-))

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

>     function "'Image" (X : Integer) return String; 
>     X'Image <=> "'Image" (X)

I read that idea several times here and elsewhere. It seems logical indeed. Has it been directly refused ? If so what was their rational ?

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[J-P. Rosen]

Le 18/01/2018 à 13:21, Mehdi Saada a écrit :
>> function "'Image" (X : Integer) return String; X'Image <=> "'Image"
>> (X)
> 
> I read that idea several times here and elsewhere. It seems logical
> indeed. Has it been directly refused ? If so what was their rational?
> 
It would defeat the whole benefit of attributes.

Attributes are constants or subprograms that are provided automatically
by the compiler. In a sense, their names are just like identifiers with
a ''' in the middle (OK lawyers, it's not really true, but it is close
enough for the casual user). This way, 1) it is clear that it is
provided by the compiler, and 2) it cannot clash with any user-defined
identifier.

If the user were allowed to define identifiers with a quote, these would
not be true any more, and there would be no benefit in using a
distinctive syntax.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 18/01/2018 14:08, J-P. Rosen wrote:

> If the user were allowed to define identifiers with a quote, these would
> not be true any more, and there would be no benefit in using a
> distinctive syntax.

As if there were any benefit of.

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p3qe4m$t5n$1@gioia.aioe.org...
> On 18/01/2018 14:08, J-P. Rosen wrote:
>
>> If the user were allowed to define identifiers with a quote, these would
>> not be true any more, and there would be no benefit in using a
>> distinctive syntax.
>
> As if there were any benefit of.

The benefit is that these things can express ideas that aren't possible for 
ordinary subprogram calls. To express Subtype'First as a function, one would 
have to have some sort of meta-type (a subtype parameter). You'd also have 
to allow "univeral_integer" and the like as expressible data types (meaning 
that you'd have to decide what they mean at runtime). All things that could 
be done -- in a new language -- but it would be extremely difficult to 
define such things and keep compatibility with existing Ada.

                          Randy.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 19/01/2018 02:10, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p3qe4m$t5n$1@gioia.aioe.org...
>> On 18/01/2018 14:08, J-P. Rosen wrote:
>>
>>> If the user were allowed to define identifiers with a quote, these would
>>> not be true any more, and there would be no benefit in using a
>>> distinctive syntax.
>>
>> As if there were any benefit of.
> 
> The benefit is that these things can express ideas that aren't possible for
> ordinary subprogram calls.

That does not justify special syntax. E.g. initialization cannot be 
expressed as a subprogram call either, nevertheless there is no special 
syntax for declaration of objects with non-null initialization.

> To express Subtype'First as a function, one would
> have to have some sort of meta-type (a subtype parameter).

I don't think this is related.

(However I am glad that you begin to see subtypes as proper types. (:-))

> You'd also have
> to allow "univeral_integer" and the like as expressible data types (meaning
> that you'd have to decide what they mean at runtime). All things that could
> be done -- in a new language -- but it would be extremely difficult to
> define such things and keep compatibility with existing Ada.

You know that I disagree with this. In my view it is possible to allow

1. interfaces and class-wides for scalar types

2. cloning of type hierarchies by Ada 83 style

    type Y is new X;

Universal_Integer would be a parent of any integer type in its hierarchy.

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p3sbkb$1msl$1@gioia.aioe.org...
> On 19/01/2018 02:10, Randy Brukardt wrote:
...
>> The benefit is that these things can express ideas that aren't possible 
>> for
>> ordinary subprogram calls.
>
> That does not justify special syntax. E.g. initialization cannot be 
> expressed as a subprogram call either, nevertheless there is no special 
> syntax for declaration of objects with non-null initialization.

??? ":=" is the special syntax of initialization (it's not the syntax of a 
subprogram call!). Your example seems to prove my point. :-)

>> To express Subtype'First as a function, one would
>> have to have some sort of meta-type (a subtype parameter).
>
> I don't think this is related.
>
> (However I am glad that you begin to see subtypes as proper types. (:-))

A type parameter clearly would have to pass the subtype information as well, 
since Ada does not allow naming of types. In this case, it is the subtype 
information that is most relevant. So I don't see your point or joke. (And I 
don't see why you don't think it is related, either. One has to have some 
mechanism for getting this information, and if you eliminate the special 
mechanism for that, some replacement is needed. In the proposed language, 
only a subprogram call is available, unless some other special syntax is 
invented, which is just kicking the can.)

>> You'd also have
>> to allow "univeral_integer" and the like as expressible data types 
>> (meaning
>> that you'd have to decide what they mean at runtime). All things that 
>> could
>> be done -- in a new language -- but it would be extremely difficult to
>> define such things and keep compatibility with existing Ada.
>
> You know that I disagree with this. In my view it is possible to allow
>
> 1. interfaces and class-wides for scalar types
>
> 2. cloning of type hierarchies by Ada 83 style
>
>    type Y is new X;
>
> Universal_Integer would be a parent of any integer type in its hierarchy.

We actually agree on this: I didn't say it wasn't possible, only that it 
would be "extremely difficult" to define it and both keep compatibility as 
well as convincing all of the stakeholders that it kept compatibility. If 
you win the Powerball Jackpot, please hire me to try. ;-)

                                          Randy.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 2018-01-20 01:42, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p3sbkb$1msl$1@gioia.aioe.org...
>> On 19/01/2018 02:10, Randy Brukardt wrote:
> ...
>>> The benefit is that these things can express ideas that aren't possible
>>> for
>>> ordinary subprogram calls.
>>
>> That does not justify special syntax. E.g. initialization cannot be
>> expressed as a subprogram call either, nevertheless there is no special
>> syntax for declaration of objects with non-null initialization.
> 
> ??? ":=" is the special syntax of initialization (it's not the syntax of a
> subprogram call!). Your example seems to prove my point. :-)

I meant rather this:

    type T is new Ada.Finalization.Controlled with ...

    X : T;
    Y : Integer;

>>> To express Subtype'First as a function, one would
>>> have to have some sort of meta-type (a subtype parameter).
>>
>> I don't think this is related.
>>
>> (However I am glad that you begin to see subtypes as proper types. (:-))
> 
> A type parameter clearly would have to pass the subtype information as well,

Yes, like it does with array bounds, *if* it were a subprogram proper. 
This is irrelevant because it is not a subprogram, it only has a syntax 
of a subprogram call. But for the compiler it is a special case exactly 
like it is when the attribute syntax is used, or any other syntax. The 
detection does not require special syntax, that is the point. Once the 
compiler detects the case, the magic starts to work.

> since Ada does not allow naming of types. In this case, it is the subtype
> information that is most relevant. So I don't see your point or joke.

It was frequently argued that subtypes are not types but something, 
well, something...

> (And I
> don't see why you don't think it is related, either. One has to have some
> mechanism for getting this information, and if you eliminate the special
> mechanism for that, some replacement is needed. In the proposed language,
> only a subprogram call is available, unless some other special syntax is
> invented, which is just kicking the can.)

It is the same mechanism used to pass/eliminate array bounds. It could 
be generalized for all types including non-tagged classes. The type tag 
of a non-tagged type is a [sub]type constraint to be passed or not. The 
same case is represented by dimensioned values. The dimension is a 
constraint, again passed or not down to the subprogram, kept or not in 
an instance.

I think it is possible to design common rules for all this and make the 
language quite simple.

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p3v378$1mqo$1@gioia.aioe.org...
> On 2018-01-20 01:42, Randy Brukardt wrote:
...
>> A type parameter clearly would have to pass the subtype information as 
>> well,
>
> Yes, like it does with array bounds, *if* it were a subprogram proper. 
> This is irrelevant because it is not a subprogram, it only has a syntax of 
> a subprogram call. But for the compiler it is a special case exactly like 
> it is when the attribute syntax is used, or any other syntax. The 
> detection does not require special syntax, that is the point. Once the 
> compiler detects the case, the magic starts to work.

Actually, a "special case" that uses typical syntax is not special at all, 
as a compiler has to start with recognizing and interpreting the normal 
syntax. In order to do that for Ada, one would have to have meta-types in 
order that the techniques would work with the resolution rules. It could be 
similar to the rules for universal_integer (needed to allow compile-time 
type-less expressions), but there would have to be something.

Yes, of course such special cases are not a problem for code 
generation/execution -- indeed, a "subprogram call" is just a mess of 
special cases to the point that there hardly is a "normal" case. (Remember 
that operators are "subprogram calls" in Ada, so many programs have more 
special cases than they do usual calls.)

...
>> (And I
>> don't see why you don't think it is related, either. One has to have some
>> mechanism for getting this information, and if you eliminate the special
>> mechanism for that, some replacement is needed. In the proposed language,
>> only a subprogram call is available, unless some other special syntax is
>> invented, which is just kicking the can.)
>
> It is the same mechanism used to pass/eliminate array bounds.

??? For Janus/Ada, at least, the array bounds ARE the object; the compiler 
only pays attention to the array data when it is directly accessed. (There 
is a pointer to the data stored with the bounds.) There is no separate 
"array bounds" mechanism; it is all tied to the subtype conversion 
mechanism.

One would need a separate mechanism to pass bounds by themselves -- not 
particular hard to do, but it would need a data type to represent "array 
bounds without any data".

> It could be generalized for all types including non-tagged classes. The 
> type tag of a non-tagged type is a [sub]type constraint to be passed or 
> not. The same case is represented by dimensioned values. The dimension is 
> a constraint, again passed or not down to the subprogram, kept or not in 
> an instance.
>
> I think it is possible to design common rules for all this and make the 
> language quite simple.

As before, I don't doubt this. I do doubt that it could be done with an 
acceptable level of compatibility. The additional overloading of subtypes 
needed would certainly cause ambiguities and care would have to be taken to 
avoid beaujolias effects.

If one was abandoning compatibility here altogether, then of course you are 
right -- and objects/exceptions should be overloadable to greatly reduce the 
visibility issues that come from use clauses -- and probably a dozen other 
minor fixes (like redoing renames so that static matching is required rather 
than ignoring the subtypes) should be done too. But that's not very likely 
to happen.

                                 Randy.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[AdaMagica]

Am Donnerstag, 18. Januar 2018 09:34:51 UTC+1 schrieb Dmitry A. Kazakov:
> You can rename result of a function too. (It does make much sense in the 
> case of scalar values returned by value).
> 
> However you cannot rename a non-object. A subtle distinction, but it is 
> there. That would prevent renaming of an attribute Object'Length which 
> is not an object for whatever strange reason.

Simple. Attribute Length is universam_integer.

> Attributes have a long 
> history of being queer. E.g. "abc"'Length is still illegal, AFAIK. In 
> Ada attributes are not considered operations as they should.

Back to Ada 80/83:

A requirement on all predefinied operations on scalar types was that they could not be hidden - so they had to be operators. Ada 80 had Abs as a function name, which was accordingly changed to "abs".
So everything else had to use some other syntax - this was chosen to be attributes.

And since Length has no relation to the index type, but had to be usable for any integer type, the solution was universal_integer, as was also chosen for some others.

And of course are attributes operations (see RM, for instance 3.5.5) - they are not operators!

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

Since universal_integer is meant to be compatible with everything, and since Ada83 is long gone,
could "function Length return Integer renames Object_Array'Length" be accepted now ? I don't think it could break any existing code to accept something that wasn't.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[J-P. Rosen]

Le 18/01/2018 à 15:17, Mehdi Saada a écrit :
> Since universal_integer is meant to be compatible with everything,
> and since Ada83 is long gone, could "function Length return Integer
> renames Object_Array'Length" be accepted now ? I don't think it could
> break any existing code to accept something that wasn't.
> 

Why do you insist on renaming a /value/ as a /function/? The following
will do exactly the same thing:

Length : constant Integer := Object_Array'Length;

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

I wanted to rename an attribute as an object at first... Length : Integer renames Object_Array'Length
Just because I'm obstinate and love renaming :-PP
Fine, I can live without :-P

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:8e553cd1-0822-4572-a41b-a7aaaa424b46@googlegroups.com...
>I wanted to rename an attribute as an object at first... Length : Integer 
>renames Object_Array'Length

We're considering this (specifically, making everything an object so it can 
be renamed). But I tried it and couldn't figure out how to do it without 
writing a definition for the meaning of object for each and every 
non-subprogram attribute (which is most of them), so I've (personally) given 
up. Others are planning to try (we'll see if they succeed).

                                                Randy.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[AdaMagica]

Am Donnerstag, 18. Januar 2018 15:17:05 UTC+1 schrieb Mehdi Saada:
> Since universal_integer is meant to be compatible with everything, and since Ada83 is long gone,
> could "function Length return Integer renames Object_Array'Length" be accepted now ? I don't think it could break any existing code to accept something that wasn't.

There's still lots of Ada 83 code around in the embedded world.
And Ada 95 didn't abolish universal_integer.

Please dive into the very heart of the definition of numeric types in Ada before you claim such nonsense.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 2018-01-18 17:48, AdaMagica wrote:
> Am Donnerstag, 18. Januar 2018 15:17:05 UTC+1 schrieb Mehdi Saada:
>> Since universal_integer is meant to be compatible with everything, and since Ada83 is long gone,
>> could "function Length return Integer renames Object_Array'Length" be accepted now ? I don't think it could break any existing code to accept something that wasn't.
> 
> There's still lots of Ada 83 code around in the embedded world.
> And Ada 95 didn't abolish universal_integer.

It could not be abolished, not without proper classes and interfaces of 
integer types.

What one can do is to resolve the issues with universal integers during 
run-time. Either it must be strictly static compile-time or else a 
proper type with named run-time instances and user-defined operations.

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Mehdi Saada]

>> Since universal_integer is meant to be compatible with everything, and since Ada83 is long gone, 
>> could "function Length return Integer renames Object_Array'Length" be accepted now ? I don't think it could break any existing code to accept something that wasn't. 

>There's still lots of Ada 83 code around in the embedded world. 
>And Ada 95 didn't abolish universal_integer. 

I know that. "abolish" meant "the internal logic and constraints of Ada83 not being the same anymore", no more (sorry, wrong word).
I wonder what already existing code PRECISELY would be broken, if the NEW norm (202x) would allow that construct. Since it was NOT present in older programs, how it being used in NEW ONES, could be a prolem ? Or gives a real world exemple, so I can get your point, AdaMagica.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:b899a060-6c72-4771-b204-8470ebe6205c@googlegroups.com...
...
>I wonder what already existing code PRECISELY would be broken, if the NEW
>norm (202x) would allow that construct. Since it was NOT present in older
>programs, how it being used in NEW ONES, could be a prolem ? Or gives
>a real world exemple, so I can get your point, AdaMagica.

It wouldn't break any code, it just doesn't make sense to rename a value or 
object as a function. These are different kinds of entities! You can't say:

     function Foobar return Integer renames Some_Object;

either. It makes sense to rename it as an object, or to just use it to 
initialize a constant object.

                    Randy.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[AdaMagica]

Am Donnerstag, 18. Januar 2018 17:59:57 UTC+1 schrieb Dmitry A. Kazakov:
> It could not be abolished, not without proper classes and interfaces of 
> integer types.
> 
> What one can do is to resolve the issues with universal integers during 
> run-time. Either it must be strictly static compile-time or else a 
> proper type with named run-time instances and user-defined operations.

Ah, I do not think so. See how Ada 83 had still Beaujolais effects (albeit very difficult to obtain) and see how Ada 95 with its well balanced universal_integer (no operators) and root_integer (with operator) types avoids these problems.

Making universal_integer type proper would ruin the whole basis.

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[Dmitry A. Kazakov]

On 2018-01-19 17:15, AdaMagica wrote:

> Making universal_integer type proper would ruin the whole basis.

I don't see why. In any case if not type then it must be strictly 
static. It cannot be both ways.

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

Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782

[G.B.]

On 18.01.18 15:17, Mehdi Saada wrote:
> Since universal_integer is meant to be compatible with everything, and since Ada83 is long gone,
> could "function Length return Integer renames Object_Array'Length" be accepted now ? I don't think it could break any existing code to accept something that wasn't.
> 

There is more to 'Image, which is a type attribute like 'Size.
Handling types is the realm of compilers.

Consider 'Value, which is paired with 'Image. Suppose there is
an enumeration subtype like that of

    type T is ('$', '¥', '£');

We now have

    X = T'Value (T'Image (X))

and, usually,

    S = T'Image (T'Value (S))


However, given the history of String design in programming
languages, things have become tricky.

Not because of a lack of symmetry between 'Image and 'Value
as written above.
Rather, I think, because of that tendency in language design
which bows before elementary school training. Hence,
Ada has removed symmetry: for example, in place of making
"+" a required part of numeric literals such as are input
to 'Image, it can be omitted. So, these values are now all
equal in Ada:

  Positive'Value ("42")
  Positive'Value (" 42")
  Positive'Value ("+42")
  Positive'Value ("   42  ")
  Positive'Value ("+42        ")

Very flexible and convenient, at first sight, I think. And done
for good reasons, at the time, perhaps: because, for output,
everyone would use an instance of a package from Text_IO,
and not 'Image. Right? No problem could have been anticipated.

This design decision has led to an endless discussion about
leading spaces in the result of 'Image for non-negatives.
At the root, elementary school habits in engineering make
programmers proudly dismiss the idea of writing numbers
symmetrically, with signs for both negatives and positives,
and maybe some technical prefix like " " attached to (non-FPT) 0.

OTOH, if programmers are smart enough to handle the compiler's
job of defining 'Image and 'Value, they are able to perform
well as substitutes: by providing the compiler with all correct
implementations for parsing and printing all user-defined literals
of any user-defined type.