Image attribute (yet again)

Image attribute (yet again)

[Stephen Davies]

Whilst looking at the new features for Ada 2020, I spotted:

 An implementation may transform the image generated by the default
 implementation of S'Put_Image for a composite subtype S in the
 following ways: 

 - If S is a composite subtype, the leading character of the image of
   a component value or index value is a space, and the immediately
   preceding character is an open parenthesis, then the space may be
   omitted. The same transformation is also permitted if the leading
   character of the component image is a space (in which case one of
   the two spaces may be omitted). [AARM note: This means that it is
   permitted to generate "(1 => 123, 2 => 456)" instead of
   "( 1 => 123, 2 => 456)".] 

Whilst it is nice that those in charge of the language are finally
acknowledging how annoying the leading space on numeric images is,
that just makes it more galling that they appear to still be doing
about it for scalar numeric types.

I understand that the default behaviour of "'Image" cannot possibly
be changed as it would cause massive incompatibility. But there are
other, simple solutions, e.g. new attribute, optional parameters, ...

One justification that might be given for doing nothing is that
"Trim(S'Image, Left)" can be used instead, but I disagree because:

- It requires adding with/use clauses for Ada.Strings and
  Ada.Strings.Fixed.

- "S'Trim_Image" would still be nicer (just as "First_Element(C)"
  can be used instead of "Element(First(C))".

Re: Image attribute (yet again)

[Stephen Davies]

On Monday, 20 April 2020 16:24:19 UTC+1, Stephen Davies  wrote:

> [yet another request for S'Trim_Image or Integer'Image(Arg,Width)
>  & Real'Image(Arg,Fore,Aft,Exp) or ...]

I guess people are sick of talking about this long-standing problem.
Personally, I'm more sick of its continued existence after 37yrs!

One observation: Since the introduction of Object'Image, which cannot
have optional integer parameters because I'Image(3) would be ambiguous,
I guess something like Trim_Image would be the simpler solution.

Re: Image attribute (yet again)

[J-P. Rosen]

Le 26/04/2020 à 00:35, Stephen Davies a écrit :
> I guess people are sick of talking about this long-standing problem.
> Personally, I'm more sick of its continued existence after 37yrs!
> 
Personnaly, I am sick of people wanting to change the language just to
save having to write a three-line function.

'Image is not intending for elaborate formatting, it's a quick debugging
help. Text_IO has all formatting features for proper IO. Since every
program has different formatting needs, you have to write you own function.


-- 
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: Image attribute (yet again)

[Jere]

On Sunday, April 26, 2020 at 2:05:59 AM UTC-4, J-P. Rosen wrote:
> Le 26/04/2020 à 00:35, Stephen Davies a écrit :
> 'Image is not intending for elaborate formatting, it's a quick debugging
> help. Text_IO has all formatting features for proper IO. Since every
> program has different formatting needs, you have to write you own function.
> 
This might be a good time to ask since this comes up all the time
for me, but where are the formatting options for hexadecimal 
to String.  All I have found so far is the Put operation
in the various "_IO" packages and generics, but it isn't 
useful at all for formatting hexadecimal values in real world
scenarios.  I pretty much reinvent the wheel each time
I have some variant of needing this functionality.  One of
these days I'll get around to making my own generic
version of it, but if the Ada standard provides a means
to do it, that would be optimal.  The only option I have
found is the Put operation, but it is pretty abysmal to
use.  Are there any solutions to this that I am missing
from within the Ada standard?

Re: Image attribute (yet again)

[Jeffrey R. Carter]

On 4/26/20 4:16 PM, Jere wrote:
>>
> This might be a good time to ask since this comes up all the time
> for me, but where are the formatting options for hexadecimal
> to String.  All I have found so far is the Put operation
> in the various "_IO" packages and generics, but it isn't
> useful at all for formatting hexadecimal values in real world
> scenarios.  I pretty much reinvent the wheel each time
> I have some variant of needing this functionality.  One of
> these days I'll get around to making my own generic
> version of it, but if the Ada standard provides a means
> to do it, that would be optimal.  The only option I have
> found is the Put operation, but it is pretty abysmal to
> use.  Are there any solutions to this that I am missing
> from within the Ada standard?

I can't tell what problem you're talking about. Ada.Text_IO's numeric-I/O pkgs, 
sometimes combined with String-handling functions and basic 1-D array operations 
seem to provide everything one could want.

Pkg PragmARC.Images has been around for a long time and provides generic Image 
functions for numeric types with width, zero-fill, and base options.

https://github.com/jrcarter/PragmARC

-- 
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

Re: Image attribute (yet again)

[Jere]

On Sunday, April 26, 2020 at 1:09:12 PM UTC-4, Jeffrey R. Carter wrote:
> On 4/26/20 4:16 PM, Jere wrote:
> >>
> > This might be a good time to ask since this comes up all the time
> > for me, but where are the formatting options for hexadecimal
> > to String.  All I have found so far is the Put operation
> > in the various "_IO" packages and generics, but it isn't
> > useful at all for formatting hexadecimal values in real world
> > scenarios.  I pretty much reinvent the wheel each time
> > I have some variant of needing this functionality.  One of
> > these days I'll get around to making my own generic
> > version of it, but if the Ada standard provides a means
> > to do it, that would be optimal.  The only option I have
> > found is the Put operation, but it is pretty abysmal to
> > use.  Are there any solutions to this that I am missing
> > from within the Ada standard?
> 
> I can't tell what problem you're talking about. Ada.Text_IO's numeric-I/O pkgs, 
> sometimes combined with String-handling functions and basic 1-D array operations 
> seem to provide everything one could want.
> 
I'm not saying it can't be done.  I'm saying by the time I go through
all the processing needed, I might as well wrote my own function.  It
makes the existing operation mostly useless (unless I just want a 
temporary debug print that I don't care how it looks).  For example,
if I want to print to a 16x2 character LCD screen and I want to print
0 padded 4 digit hex values with no "16#" prefix or "#" ending, then
I need to call Put with an 8 character string, search for the first
occurrence of '#' (it can be in multiple locations), then overwrite
a variable number of those characters with 0's (based on the location
of '#'), and then extract the 4 digits I actually need.  All doable 
(not saying it cannot be done), but at that point, I am better off 
just doing my own custom operation instead instead of even using the
Put operation.  It feels like the Put operation wasn't designed 
with usability in mind.  Just the presence of the "16#" and "#" 
around the value makes using the operation more clunky than it 
should be.  If that had been left out or if the operation at least
allowed for padding the actual numeric value inside the result,
then it would have been much more usable.

I was hoping that there was a better formatting operation for 
non base 10 number formatting that I wasn't aware of as it was
alluded that Text_IO had all the necessary formatting features.
I am still finding new stuff in the Ada standard each day, so 
I was hoping I had just missed something.  J.P. Rosen has a much
better experience and knowledge of the standard than me, so I 
was hoping he could point me to something that was better than
what I currently knew of.  If there isn't, then no biggie, I'll
just keep writing custom functions.

Re: Image attribute (yet again)

[J-P. Rosen]

Le 26/04/2020 à 19:33, Jere a écrit :
> I'm not saying it can't be done.  I'm saying by the time I go through
> all the processing needed, I might as well wrote my own function.  It
> makes the existing operation mostly useless (unless I just want a 
> temporary debug print that I don't care how it looks).  For example,
> if I want to print to a 16x2 character LCD screen and I want to print
> 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then
> I need to call Put with an 8 character string, search for the first
> occurrence of '#' (it can be in multiple locations), then overwrite
> a variable number of those characters with 0's (based on the location
> of '#'), and then extract the 4 digits I actually need.  All doable 
> (not saying it cannot be done), but at that point, I am better off 
> just doing my own custom operation instead instead of even using the
> Put operation.  
Right. If you want you own format, write it. It will take you less time
than writing this message. For the benefit of everybody, here it is:

   Hex_Digits : constant array (Bits_16 range 0..15) of Character
      := "0123456789ABCDEF";
   function Hex_Image (Value : Bits_16) return String is
      Result  : String (1 .. 4);
      Current : Bits_16 := Value;
   begin
      for I in reverse Result'Range loop
         Result (I) := Hex_Digits (Current mod 16);
         Current    := Current / 16;
      end loop;
      return Result;
   end Hex_Image;

> It feels like the Put operation wasn't designed 
> with usability in mind.  Just the presence of the "16#" and "#" 
> around the value makes using the operation more clunky than it 
> should be.  If that had been left out or if the operation at least
> allowed for padding the actual numeric value inside the result,
> then it would have been much more usable.

Text_IO was designed for file operations, not so much for interactive
IO. And there is an important feature of Text_IO which is rarely
mentioned: If you use only the appropriate operations from Text_IO (no
'Image), and your program writes into a file, you can take the sequence
of code that writes the file, replace every Put_* operation by the
symetric Get_* operation, and you will read the file without error.

This feature requires that if you write a number in a certain base, then
you need to recognize the base when reading. So it's not an error, but a
design decision. Of course, like any design decision, you may agree with
it or not.
-- 
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: Image attribute (yet again)

[Jere]

On Monday, April 27, 2020 at 8:33:31 AM UTC-4, J-P. Rosen wrote:
> Le 26/04/2020 à 19:33, Jere a écrit :
> > I'm not saying it can't be done.  I'm saying by the time I go through
> > all the processing needed, I might as well wrote my own function.  It
> > makes the existing operation mostly useless (unless I just want a 
> > temporary debug print that I don't care how it looks).  For example,
> > if I want to print to a 16x2 character LCD screen and I want to print
> > 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then
> > I need to call Put with an 8 character string, search for the first
> > occurrence of '#' (it can be in multiple locations), then overwrite
> > a variable number of those characters with 0's (based on the location
> > of '#'), and then extract the 4 digits I actually need.  All doable 
> > (not saying it cannot be done), but at that point, I am better off 
> > just doing my own custom operation instead instead of even using the
> > Put operation.  
> Right. If you want you own format, write it. It will take you less time
> than writing this message. For the benefit of everybody, here it is:
> 
>
Yep, I do something similar to what you posted.  I was just
asking if the standard provided something more than what
Put provided as it wasn't quite adequate for the general case.  
It sounds like from your answer that I didn't miss
it (I was hoping!).  As I said earlier, for stuff like this 
I have generally rolled my own in Ada.  

> 
> > It feels like the Put operation wasn't designed 
> > with usability in mind.  Just the presence of the "16#" and "#" 
> > around the value makes using the operation more clunky than it 
> > should be.  If that had been left out or if the operation at least
> > allowed for padding the actual numeric value inside the result,
> > then it would have been much more usable.
> 
> Text_IO was designed for file operations, not so much for interactive
> IO. And there is an important feature of Text_IO which is rarely
> mentioned: If you use only the appropriate operations from Text_IO (no
> 'Image), and your program writes into a file, you can take the sequence
> of code that writes the file, replace every Put_* operation by the
> symetric Get_* operation, and you will read the file without error.
> 
> This feature requires that if you write a number in a certain base, then
> you need to recognize the base when reading. So it's not an error, but a
> design decision. Of course, like any design decision, you may agree with
> it or not.

Conceptionally that makes sense.  I do wish they had followed other
languages in at least providing some of the basic formatting options
for stuff like this.  Even if it was a different package (String_IO?).

Re: Image attribute (yet again)

[J-P. Rosen]

Le 27/04/2020 à 14:50, Jere a écrit :
> Conceptionally that makes sense.  I do wish they had followed other
> languages in at least providing some of the basic formatting options
> for stuff like this.  Even if it was a different package (String_IO?).

There are plenty of packages that you can download that provide very
useful stuff. The difference with other languages is that Ada people
disregard anything which is not blessed by the standard. Many other
in-fashion languages have not standard at all, so users consider that
anything on the web is "available for the language".

If you look at any of the sites that provide Ada resources links, you'll
see that Ada's situation is not that bad...

Talking about reuse vs. redesign, I recommend the paper "What price
reusability", old but fortunately available from ACM:
https://dl.acm.org/doi/10.1145/112629.112643

It compares the cost of rewriting with the cost of searching for
something already available, and the number of reuses necessary to break
even. It shows that for simple things (like the one we discussed above),
rewriting can be more cost-effective than searching the web for existing
stuff...

-- 
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: Image attribute (yet again)

[Jere]

On Monday, April 27, 2020 at 9:42:39 AM UTC-4, J-P. Rosen wrote:
> Le 27/04/2020 à 14:50, Jere a écrit :
> > Conceptionally that makes sense.  I do wish they had followed other
> > languages in at least providing some of the basic formatting options
> > for stuff like this.  Even if it was a different package (String_IO?).
> 
> There are plenty of packages that you can download that provide very
> useful stuff. The difference with other languages is that Ada people
> disregard anything which is not blessed by the standard. Many other
> in-fashion languages have not standard at all, so users consider that
> anything on the web is "available for the language".
I was more referring to things that are considered part of the standard 
language (text formatting of numbers is standard in many languages).


> If you look at any of the sites that provide Ada resources links, you'll
> see that Ada's situation is not that bad...
It depends on what your use case is.  In some areas, the situation
is quite bad, in others it is not.  I am hoping that as some more 
mainstream companies like Nvidia take up Ada, the landscape will improve 
even more.  

> 
> Talking about reuse vs. redesign, I recommend the paper "What price
> reusability", old but fortunately available from ACM:
> https://dl.acm.org/doi/10.1145/112629.112643
> 
> It compares the cost of rewriting with the cost of searching for
> something already available, and the number of reuses necessary to break
> even. It shows that for simple things (like the one we discussed above),
> rewriting can be more cost-effective than searching the web for existing
> stuff...
> 
Thanks!  I'll take a look.  

Re: Image attribute (yet again)

[Jeffrey R. Carter]

On 4/27/20 3:42 PM, J-P. Rosen wrote:
> 
> It compares the cost of rewriting with the cost of searching for
> something already available, and the number of reuses necessary to break
> even. It shows that for simple things (like the one we discussed above),
> rewriting can be more cost-effective than searching the web for existing
> stuff...

That's a mischaracterization of the paper. It actually compares the cost of 
implementing and using an application-specific component to implementing and 
using a reusable component.

Going to adaic.org and finding a library you like takes longer than writing a 
little subprogram like the one under discussion, but a lot less time than 
writing such subprograms repeatedly.

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48

Re: Image attribute (yet again)

[J-P. Rosen]

Le 27/04/2020 à 16:55, Jeffrey R. Carter a écrit :
> That's a mischaracterization of the paper. It actually compares the cost
> of implementing and using an application-specific component to
> implementing and using a reusable component.
> 
> Going to adaic.org and finding a library you like takes longer than
> writing a little subprogram like the one under discussion, but a lot
> less time than writing such subprograms repeatedly.

Well, the "break even" is measured in terms of number of reuses vs.
effort to find an existing component. Of course, it assumes that once
you have written something yourself, you don't keep rewriting it all the
time!

-- 
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: Image attribute (yet again)

[Jere]

On Monday, April 27, 2020 at 8:33:31 AM UTC-4, J-P. Rosen wrote:
> Le 26/04/2020 à 19:33, Jere a écrit :
> > I'm not saying it can't be done.  I'm saying by the time I go through
> > all the processing needed, I might as well wrote my own function.  It
> > makes the existing operation mostly useless (unless I just want a 
> > temporary debug print that I don't care how it looks).  For example,
> > if I want to print to a 16x2 character LCD screen and I want to print
> > 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then
> > I need to call Put with an 8 character string, search for the first
> > occurrence of '#' (it can be in multiple locations), then overwrite
> > a variable number of those characters with 0's (based on the location
> > of '#'), and then extract the 4 digits I actually need.  All doable 
> > (not saying it cannot be done), but at that point, I am better off 
> > just doing my own custom operation instead instead of even using the
> > Put operation.  
> 
> This feature requires that if you write a number in a certain base, then
> you need to recognize the base when reading. So it's not an error, but a
> design decision. Of course, like any design decision, you may agree with
> it or not.
As I have thought about this more, I don't think I see the need
for the "16#" and associated for this functionality to work.  If you
are using the reflective Get to the Put, that knows the base.  The
text doesn't need to specify it. If you want something more runtime
adaptive, then sure, but for pure reflective Get/Put it isn't needed
that I can tell.  In the case where a more runtime adaptive strategy
is desired, that is where I would have expected the language to want
you to roll one's own logic.

Re: Image attribute (yet again)

[J-P. Rosen]

Le 27/04/2020 à 16:10, Jere a écrit :
>> This feature requires that if you write a number in a certain base, then
>> you need to recognize the base when reading. So it's not an error, but a
>> design decision. Of course, like any design decision, you may agree with
>> it or not.
> As I have thought about this more, I don't think I see the need
> for the "16#" and associated for this functionality to work.  If you
> are using the reflective Get to the Put, that knows the base.  The
> text doesn't need to specify it. If you want something more runtime
> adaptive, then sure, but for pure reflective Get/Put it isn't needed
> that I can tell.  In the case where a more runtime adaptive strategy
> is desired, that is where I would have expected the language to want

Huh? The Get procedure has no parameter for the base, it accepts
whatever is in the file.

The design principle is that you are precise on output, and tolerant on
input. Same idea with 'Image (required to be upper case) and 'Value
(accepts any case).

-- 
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: Image attribute (yet again)

[Jere]

On Tuesday, April 28, 2020 at 2:02:20 AM UTC-4, J-P. Rosen wrote:
> Le 27/04/2020 à 16:10, Jere a écrit :
> >> This feature requires that if you write a number in a certain base, then
> >> you need to recognize the base when reading. So it's not an error, but a
> >> design decision. Of course, like any design decision, you may agree with
> >> it or not.
> > As I have thought about this more, I don't think I see the need
> > for the "16#" and associated for this functionality to work.  If you
> > are using the reflective Get to the Put, that knows the base.  The
> > text doesn't need to specify it. If you want something more runtime
> > adaptive, then sure, but for pure reflective Get/Put it isn't needed
> > that I can tell.  In the case where a more runtime adaptive strategy
> > is desired, that is where I would have expected the language to want
> 
> Huh? The Get procedure has no parameter for the base, it accepts
> whatever is in the file.
> 
> The design principle is that you are precise on output, and tolerant on
> input. Same idea with 'Image (required to be upper case) and 'Value
> (accepts any case).
> 
> -- 
> 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

Yeah, I misread the RM as having the base on Get as well.

Re: Image attribute (yet again)

[Oliver Kellogg]

On Sunday, April 26, 2020 at 4:16:46 PM UTC+2, Jere wrote:
> This might be a good time to ask since this comes up all the time
> for me, but where are the formatting options for hexadecimal 
> to String.  All I have found so far is the Put operation
> in the various "_IO" packages and generics, but it isn't 
> useful at all for formatting hexadecimal values in real world
> scenarios.  I pretty much reinvent the wheel each time
> I have some variant of needing this functionality.

+1 for me - e.g. see function Hex_Str_To_Unsigned at
https://github.com/persan/auto-io-gen/blob/28e8e57c18dfd328a5abc97f3e6e12ceacd5b3c9/auto_text_io.src/auto_text_io-access_io.adb

- Oliver

Re: Image attribute (yet again)

[Oliver Kellogg]

On Sunday, April 26, 2020 at 8:40:05 PM UTC+2, Oliver Kellogg wrote:
> On Sunday, April 26, 2020 at 4:16:46 PM UTC+2, Jere wrote:
> > This might be a good time to ask since this comes up all the time
> > for me, but where are the formatting options for hexadecimal 
> > to String.  All I have found so far is the Put operation
> > in the various "_IO" packages and generics, but it isn't 
> > useful at all for formatting hexadecimal values in real world
> > scenarios.  I pretty much reinvent the wheel each time
> > I have some variant of needing this functionality.
> 
> +1 for me - e.g. see function Hex_Str_To_Unsigned at
> https://github.com/persan/auto-io-gen/blob/28e8e57c18dfd328a5abc97f3e6e12ceacd5b3c9/auto_text_io.src/auto_text_io-access_io.adb
> 
> - Oliver

Oops, I meant Hex_Str_to_Unsigned

Re: Image attribute (yet again)

[Oliver Kellogg]

On Sunday, April 26, 2020 at 8:42:09 PM UTC+2, Oliver Kellogg wrote:
> On Sunday, April 26, 2020 at 8:40:05 PM UTC+2, Oliver Kellogg wrote:
> > On Sunday, April 26, 2020 at 4:16:46 PM UTC+2, Jere wrote:
> > > This might be a good time to ask since this comes up all the time
> > > for me, but where are the formatting options for hexadecimal 
> > > to String.  All I have found so far is the Put operation
> > > in the various "_IO" packages and generics, but it isn't 
> > > useful at all for formatting hexadecimal values in real world
> > > scenarios.  I pretty much reinvent the wheel each time
> > > I have some variant of needing this functionality.
> > 
> > +1 for me - e.g. see function Hex_Str_To_Unsigned at
> > https://github.com/persan/auto-io-gen/blob/28e8e57c18dfd328a5abc97f3e6e12ceacd5b3c9/auto_text_io.src/auto_text_io-access_io.adb
> > 
> > - Oliver
> 
> Oops, I meant Hex_Str_to_Unsigned
not my day! Unsigned_to_Hex_Str

Re: Image attribute (yet again)

[Jere]

On Sunday, April 26, 2020 at 2:40:05 PM UTC-4, Oliver Kellogg wrote:
> On Sunday, April 26, 2020 at 4:16:46 PM UTC+2, Jere wrote:
> > This might be a good time to ask since this comes up all the time
> > for me, but where are the formatting options for hexadecimal 
> > to String.  All I have found so far is the Put operation
> > in the various "_IO" packages and generics, but it isn't 
> > useful at all for formatting hexadecimal values in real world
> > scenarios.  I pretty much reinvent the wheel each time
> > I have some variant of needing this functionality.
> 
> +1 for me - e.g. see function Hex_Str_To_Unsigned at
> https://github.com/persan/auto-io-gen/blob/28e8e57c18dfd328a5abc97f3e6e12ceacd5b3c9/auto_text_io.src/auto_text_io-access_io.adb
> 
> - Oliver

Thanks!  I do have a method I use (more similar to the one J.P. Rosen
had posted later on), but I'll take a look at this.

Re: Image attribute (yet again)

[Shark8]

On Sunday, April 26, 2020 at 8:16:46 AM UTC-6, Jere wrote:
> On Sunday, April 26, 2020 at 2:05:59 AM UTC-4, J-P. Rosen wrote:
> > Le 26/04/2020 à 00:35, Stephen Davies a écrit :
> > 'Image is not intending for elaborate formatting, it's a quick debugging
> > help. Text_IO has all formatting features for proper IO. Since every
> > program has different formatting needs, you have to write you own function.
> > 
> This might be a good time to ask since this comes up all the time
> for me, but where are the formatting options for hexadecimal 
> to String.

The method that I typically go with is something like:
Subtype Hex_Character is Character
  with Static_Predicate => Hex_Character in '0'..'9'|'A'..'F';
Type Nybble  is range 0..15 with Size => 4;
Type Byte    is record
  High, Low : Nybble;
end record with Size => 8;
-- Rep Clause.

Function To_Nybble( Input : Hex_Character ) return Nybble is
(case Input is
  when '0' => 16#0#,
  when '1' => 16#1#,
--...
  when 'F' => 16#F#
);

Function To_Hex_Character( Input : Nybble ) return Hex_Character is
(case Input is
  when 16#0# => '0',
  when 16#1# => '1',
--...
  when 16#F# => 'F'
);

Function Byte_to_Hex( Input : Byte ) return String is
( HexChar( Input.High ) & HexChar( Input.High ) );

Though for one application I made a proper Hex_Character character-type and used the 'pos/'val/'image/'value attributes.

You can also get easy string conversions with 'Value, especially:
Subtype Hex_String is String
  with Dynamic_Predicate => (for all C of Hex_String => C in Hex_Character);

Function Hex_to_Integer( Input : Hex_String ) return Integer is
( Integer'Image("16#"& Input &'#') );

Re: Image attribute (yet again)

[Stephen Davies]

On Sunday, 26 April 2020 07:05:59 UTC+1, J-P. Rosen  wrote:

> Personnaly, I am sick of people wanting to change the language just to
> save having to write a three-line function.

I could write a three-line function to do 'Min but I appreciate it
being party of the language.

> 'Image is not intending for elaborate formatting

Displaying numbers without extraneous spaces is hardly elaborate.

> it's a quick debugging help.

I have used 'Image in delivered code and I doubt I'm alone. Furthermore,
it's useful when first learning Ada, and the leading space is not a
good advert for students.

> Text_IO has all formatting features for proper IO.

Text_IO is somewhat lacking when it comes to formatting
(e.g. see Jere's and Oliver's replies).

A couple of additional thoughts:-

1. If Trim_Image were added then Trim_Width should also be added,
   which could be useful even when Integer_IO.Put is being used.

2. If the language won't change (and maybe even if it does change)
   perhaps if would be nice if Gnat added S'Trmg (c.f. S'Img).