ADA and return functions (Strings)

ADA and return functions (Strings)

[ProLogic]

Why does ADA return extra spaces in for example the following function...

 function getVersion return String is
  begin
   return Version.Major'img & "." & Version.Minor'img;
  end;

thanks
ProLogic

Re: ADA and return functions (Strings)

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "ProLogic" <ProLogic@prologitech.ods.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: May 19, 2002 2:20 AM
Subject: ADA and return functions (Strings)


> Why does ADA return extra spaces in for example the following function...
> 
>  function getVersion return String is
>   begin
>    return Version.Major'img & "." & Version.Minor'img;
>   end;
Well, ADA doesn't return anyting, but the Ada function you've supplied
above will return a string with spaces because the Image attributes of
non-negative numeric objects is defined with a leading space where the
'-' would be if the object had a negative value.  This is true even for
types that are declared not to have negative values.

The best way to do this without spaces is something like this:

return Ada.Strings.Fixed.Trim (Version.Major'img, Ada.Strings.Left) &
 "." & Ada.Strings.Fixed.Trim (Version.Minor'img, Ada.Strings.Left);

 

Re: ADA and return functions (Strings)

[ProLogic]

Thank you very much David...

----- Original Message -----
From: "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>
Newsgroups: comp.lang.ada
Sent: Sunday, May 19, 2002 8:38 PM
Subject: Re: ADA and return functions (Strings)


>
> ----- Original Message -----
> From: "ProLogic" <ProLogic@prologitech.ods.org>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: May 19, 2002 2:20 AM
> Subject: ADA and return functions (Strings)
>
>
> > Why does ADA return extra spaces in for example the following
function...
> >
> >  function getVersion return String is
> >   begin
> >    return Version.Major'img & "." & Version.Minor'img;
> >   end;
> Well, ADA doesn't return anyting, but the Ada function you've supplied
> above will return a string with spaces because the Image attributes of
> non-negative numeric objects is defined with a leading space where the
> '-' would be if the object had a negative value.  This is true even for
> types that are declared not to have negative values.
>
> The best way to do this without spaces is something like this:
>
> return Ada.Strings.Fixed.Trim (Version.Major'img, Ada.Strings.Left) &
>  "." & Ada.Strings.Fixed.Trim (Version.Minor'img, Ada.Strings.Left);
>
>
>
>

Re: ADA and return functions (Strings)

[Robert Dewar]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021804803.32634.comp.lang.ada@ada.eu.org>...

> The best way to do this without spaces is something like this:
> 
> return Ada.Strings.Fixed.Trim (Version.Major'img, Ada.Strings.Left) &
>  "." & Ada.Strings.Fixed.Trim (Version.Minor'img, Ada.Strings.Left);

Seems very heavy to drag in the whole of Ada.Strings.Fixed for such a trivial
task, and even heavier to call Trim repeatedly. Why not just write a little
function called Semsible_Image that you then call. Actually you can use the
name Image for this function.

P.S. This was clearly a bad design decision in Ada, it had in mind some kind
of columnar output thought, but that was silly in context. But we are stuck
now because people depend on the existing annoying definition.

Re: ADA and return functions (Strings)

[sk]

Hi,

dewar@gnat.com (Robert Dewar) :
> P.S. This was clearly a bad design decision in Ada ...

As anybody considered making the 'Image attribute 
user definable for Ada0x (similar to 'Input etc) ?

This would allow the "legacy" 'Image to behave as
defined and also allow for

function My_Image (...) ...

for Type'Image use My_Image;


-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: ADA and return functions (Strings)

[Marin David Condic]

Or just simply provide a new attribute. What woud stop something like:
Integer'Spaceless_Image from being easy to implement and really low impact
on the language? (O.K. Pick a better name. But besides that...:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"sk" <sknipe@ktc.com> wrote in message
news:mailman.1021839903.14611.comp.lang.ada@ada.eu.org...
>
> As anybody considered making the 'Image attribute
> user definable for Ada0x (similar to 'Input etc) ?
>
> This would allow the "legacy" 'Image to behave as
> defined and also allow for
>

Re: ADA and return functions (Strings)

[sk]

Hi,

MDC :
> ... Integer'Spaceless_Image ...

I was thinking of for more complex types, 
timestamps for example. 

A "for Time'Image use My_Time_Image" might allow
for several possibilities :

1) I want date only.
2) I want time only
3) I want yyyy-mm-dd format
4) I want mm-dd-yyyy format
5) ... etc

Instead of asking the Ada language to standardize a
date/time image format which will not meet all needs, 
allow an 'Image substitution.

It could be tricky, but I think it might have less 
impact on the language than adding special attributes, 
such as "Spaceless_Image", to the predefined set of 
attributes.

In many ways, the 'Image and 'Value attributes have
parallels to the 'Read and 'Write attributes in terms 
of allowing the caller to define the presentation of
I/O data formats.

I realize of course, that nothing is really gained by 
'Image and 'Value substitution since they are directed
at the definite string type and 'Read and 'Write are 
directed at the abstract stream, but it could provide
a solution to the statement 

dewar@gnat.com (Robert Dewar) :
> ... But we are stuck now because people depend on 
> the existing annoying definition.

Let "people" depend upon their own definition, let the 
language worry about more critical things.

Another possible benefit is that one could define a 
simple "Hex_Image" function for example. One could 
then substitute with 

"for My_Integer_Type'Image use Hex_Image;" 

instead of having to instantiate an Ada.Text_Io.Integer_Io
and setting default base etc. and then use the string 
specific "Put" (which requires a constrained string, and
was a secondary point of another thread a week or two ago).

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: ADA and return functions (Strings)

[John English]

sk wrote:
> 
> Hi,
> 
> MDC :
> > ... Integer'Spaceless_Image ...
> 
> I was thinking of for more complex types,
> timestamps for example.
> 
> A "for Time'Image use My_Time_Image" might allow
> for several possibilities :

I seem to remember that user-defined attributes were in one of the
earlier Ada 9X mapping docs, but they were dropped at some point in
the revision process. Can anyone remember any of the details (like
why the idea was dropped)?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: ADA and return functions (Strings)

[Marin David Condic]

The idea has merit, but I'd still like to have an attribute that gave me
what I want for the standard types without any effort on my part to override
it. There might be times when I'd like to override 'Image with something of
my own (and 'Value?) but when I just want quick & dirty conversion to a
string - sans leading space - I'd hate to have to write code of my own.
Otherwise why not simply encase Integer'Image(something) in an editing
function?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"sk" <sknipe@ktc.com> wrote in message
news:mailman.1021949581.28481.comp.lang.ada@ada.eu.org...
>
> I was thinking of for more complex types,
> timestamps for example.
>

Re: ADA and return functions (Strings)

[Ted Dennison]

sk <sknipe@ktc.com> wrote in message news:<mailman.1021949581.28481.comp.lang.ada@ada.eu.org>...
> Instead of asking the Ada language to standardize a
> date/time image format which will not meet all needs, 
> allow an 'Image substitution.

It has been suggested here before, yes. I understand that it was even
proposed for Ada95, but the cost/benifit ratio was deemed not low
enough.


> In many ways, the 'Image and 'Value attributes have
> parallels to the 'Read and 'Write attributes in terms 
> of allowing the caller to define the presentation of
> I/O data formats.

If one were to use the same mechanisim that those attributes use, then
the existing language rules would diallow overriding these attributes
anywhere but the compilation unit (typically package spec) in which
their types are declared. Thus you still could not use this mechanism
to "fix" the leading spaces on the predefined types.

However, you could define your own types derived from them which have
more sensible images. So you could make something like:

type DD_MM_YY_HHMMSS is new Ada.Calendar.Time;
type Day_Month_Year is new Ada.Calendar.Time;
for DD_MM_YY_HHMMSS'image use DD_MM_YY_HHMMSS_Image;
...
Ada.Text_IO.Put_Line ("Basic Stamp: " & 
  DD_MM_YY_HHMMSS'image (DD_MM_YY_HHMMSS (Ada.Calendar.Clock)));
Ada.Text_IO.Put_Line ("Readable Date Stamp: " &
  Day_Month_Year'image (Day_Month_Year (Ada.Calendar.Clock)));

Re: ADA and return functions (Strings)

[Jean-Pierre Rosen]

> sk <sknipe@ktc.com> wrote in message news:<mailman.1021949581.28481.comp.lang.ada@ada.eu.org>...
> > In many ways, the 'Image and 'Value attributes have
> > parallels to the 'Read and 'Write attributes in terms
> > of allowing the caller to define the presentation of
> > I/O data formats.
>
There is a fundamental difference though: 'Read and 'Write compose, i.e. a redefinition of T'Write will be used by any composite
type with a component of type T. OTOH, redefining 'image brings you nothing in addition to what you can do by writing an Image()
function.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA and return functions (Strings)

[sk]

Hi,
 
dennison@telepath.com (Ted Dennison) :
> ...
> for DD_MM_YY_HHMMSS'image use DD_MM_YY_HHMMSS_Image;
> ...

I didn't notice the details of your example, a mistake ?

Or is a page of the secret manuals still in hiding ?

I can get as far as "My_Time'Image (Clock)" and the 
subtyping to get a possible local scope for Time.

With that local scope one could possibly do a 'Read 
substitution etc, but after that point the example 
loses me.

... unless you are trying to illustrate the use of
a 'Image substitution and getting around the 
declarative scope of Time ?

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: ADA and return functions (Strings)

[sk]

Hi,

> ... unless you are trying to illustrate the use of
> a 'Image substitution and getting around the 
> declarative scope of Time ?

DOH ... of course it is an illustration !

It is amazing the degree of difference in comprehension 
between too little, just right and too much coffee.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: ADA and return functions (Strings)

[sk]

Hi,

dennison@telepath.com (Ted Dennison) :
> If one were to use the same mechanisim that those ...

I had of course forgotten the "local" nature of the
tick-io substitution. 

With respect to 
> type DD_MM_YY_HHMMSS is new Ada.Calendar.Time; ...

I tend to keep a package of Images lying around for
these kinds of situations.
 
"Jean-Pierre Rosen" <rosen@adalog.fr> :
> ... OTOH, redefining 'image brings you nothing ...

I agree that nothing is gained ... 

... but it would be interesting to see how many people 
almost automatically build their own image functions 
rather than use the predefined ones ...

... and also, how many people tend to avoid at all
costs using instantiations of Ada.Integer_Io and kin
along with Ada.Strings to build these Image functions ?

Anyway, I have no concern other than curiosity over the
issue. It would seem however, that putting the definition
of 'Image formats in the user domain rather than the
language standard would allow for the standard to focus 
on core features rather than periphery issues.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: ADA and return functions (Strings)

[David C. Hoos, Sr.]

----- Original Message -----
From: "Robert Dewar" <dewar@gnat.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: May 19, 2002 9:30 AM
Subject: Re: ADA and return functions (Strings)


> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message
news:<mailman.1021804803.32634.comp.lang.ada@ada.eu.org>...
>
> > The best way to do this without spaces is something like this:
> >
> > return Ada.Strings.Fixed.Trim (Version.Major'img, Ada.Strings.Left) &
> >  "." & Ada.Strings.Fixed.Trim (Version.Minor'img, Ada.Strings.Left);
>
> Seems very heavy to drag in the whole of Ada.Strings.Fixed for such a
trivial
> task, and even heavier to call Trim repeatedly. Why not just write a little
> function called Semsible_Image that you then call. Actually you can use the
> name Image for this function.
>
After having pressed the "Send" button, I thought I had been a bit
presumptuous to say "the best way ...";

Robert's comment about dragging in the whole of Ada.Strings.Fixed is certainly
appropriate, if there were no other reason to drag it in.  As far as the
overhead of calling Trim twice is concerned, I reasoned that the function
getVersion would likely be called only once, but certainly not frequently.

This, too, is presumptuous, so I offer another implementation, perhaps not
as (humanly) readable as my previous offering, but certainly more efficient:

function getVersion return String is
   Major : constant string := Version.Major'img;
   Minor : constant string := Version.Minor'img;
begin
   return Major (Major'First + 1 .. Major'Last) &
     "." & Minor (Minor'First + 1 .. Minor'Last);
end;

While we're looking at this function, I'll offer another comment.

The use of verb phrases as the names of functions is not considered the
best practice addording tho the Ada Style Guide.  Instead function names
should be noun phrases.  So I would simply name this function Version.

Re: ADA and return functions (Strings)

[Robert Dewar]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021840081.14696.comp.lang.ada@ada.eu.org>...
> The use of verb phrases as the names of functions is not 
> considered the best practice addording tho the Ada Style 
> Guide.  Instead function names should be noun phrases. 
? So I would simply name this function Version.

This is of course merely a matter of personal preference.
Personally I prefer to use the noun phrase (like Version)
if the version is something that is an immediately 
available attribute, but I incline to Get_Version if
there is significant work to do in obtaining it. It is
partly a matter of whether you think of the function as
a mathematical function, or whether you think of it as a
significant block of code that has something to do.

Anyway, choose names that sound right to you, you do not
have to follow simplistic rules :-)

Re: ADA and return functions (Strings)

[Kevin Cline]

dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0205191906.7180ac5e@posting.google.com>...
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021840081.14696.comp.lang.ada@ada.eu.org>...
> > The use of verb phrases as the names of functions is not 
> > considered the best practice addording tho the Ada Style 
> > Guide.  Instead function names should be noun phrases. 
> ? So I would simply name this function Version.
> 
> This is of course merely a matter of personal preference.
> Personally I prefer to use the noun phrase (like Version)
> if the version is something that is an immediately 
> available attribute, but I incline to Get_Version if
> there is significant work to do in obtaining it. 

Selecting the name on this basis lets
the implementation show through the interface.
Would you change the function name if you changed
the implementation to precompute the function result?

Re: ADA and return functions (Strings)

[Larry Kilgallen]

In article <ba162549.0205200729.7c70fe5c@posting.google.com>, kcline17@hotmail.com (Kevin Cline) writes:
> dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0205191906.7180ac5e@posting.google.com>...
>> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021840081.14696.comp.lang.ada@ada.eu.org>...
>> > The use of verb phrases as the names of functions is not 
>> > considered the best practice addording tho the Ada Style 
>> > Guide.  Instead function names should be noun phrases. 
>> ? So I would simply name this function Version.
>> 
>> This is of course merely a matter of personal preference.
>> Personally I prefer to use the noun phrase (like Version)
>> if the version is something that is an immediately 
>> available attribute, but I incline to Get_Version if
>> there is significant work to do in obtaining it. 
> 
> Selecting the name on this basis lets
> the implementation show through the interface.
> Would you change the function name if you changed
> the implementation to precompute the function result?

I am not Robert, but if I were to change the underlying efficiency
of a subprogram I might change the name to ensure that I revisited
all the call sites to ensure they were making appropriate use of
the subprogram in light of the new performance considerations (for
better or for worse).

Re: ADA and return functions (Strings)

[Jeffrey Carter]

ProLogic wrote:
> 
>    return Version.Major'img & "." & Version.Minor'img;

Note that 'Img is a GNAT-specific attribute.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: ADA and return functions (Strings)

[tmoran]

> Note that 'Img is a GNAT-specific attribute.
Suggesting that ACT folks think highly enough of the leading space that
they copied it from <type>'image.

Re: ADA and return functions (Strings)

[David C. Hoos, Sr.]

----- Original Message ----- 
From: <tmoran@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: May 19, 2002 8:58 PM
Subject: Re: ADA and return functions (Strings)


> > Note that 'Img is a GNAT-specific attribute.
> Suggesting that ACT folks think highly enough of the leading space that
> they copied it from <type>'image.
I don't think so, considering Robert's comments about the leading space.
The 'Img object attribute is the same function as the 'Image attribute
of the type of the object.

Re: ADA and return functions (Strings)

[tmoran]

> The 'Img object attribute is the same function as the 'Image attribute
> of the type of the object.
  Why?

Re: ADA and return functions (Strings)

[David C. Hoos, Sr.]

----- Original Message ----- 
From: <tmoran@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: May 19, 2002 10:05 PM
Subject: Re: ADA and return functions (Strings)


> > The 'Img object attribute is the same function as the 'Image attribute
> > of the type of the object.
>   Why?
The advantage of the 'Img is that its use doesn't require the use of the
type name, but can simply be ppended to the name of the object.