'Image for composite types

'Image for composite types

[Martin]

Is it just me that gets fed up with the lack of 'Image on composite
types?

I'm thinking in particular of when I'm testing / debugging and usually
end up writing lots of 'Put_Line' code for each and every record. And
then having to maintain them.

It got me thinking that the language could be expanded to include some
helper attributes for easily composing a function that could return a
String a la 'Image for scalar types.

   function record_type_definition'Component_Name (I : Positive)
return String;
   function record_type_definition'Component_Image (I : Positive)
return String;
   function record_type_definition'Number_Of_Components return
Natural;

   Example
   =======
      type Person is
         record
            Name   : Unbounded_String;
            Age    : Natural;
            Height : Float;
            Weight : Float;
         end record;
   ...
      procedure Put_Line (P : Person) is
      begin
         Put_Line (P.Name);
         for I in 2 .. Person'Number_Of_Components (P) loop
            Put_Line (Person'Component_Name (I) & " => " &
Person'Component_Image (I));
         end loop;
      end Put_Line;
   ...
      Me : Person := (Name   => To_Unbounded_String ("Martin"),
                      Age    => 40,
                      Height => 1.70,
                      Weight => 82.5);
   begin
      Put_Line (Me);
   ...

Gives output:
Martin
Age => 40
Height => 1.70
Weight => 82.5


Or I could define a generic procedure for any of my record types, e.g.

   generic
      type Record_Type is private;
   procedure Put_Line (R : Record_Type);

   procedure Put_Line (R : Record_Type) is
   begin
      -- Notice: no actual names are used at all...
      for R in 1 .. Record_Type'Number_Of_Components loop
         Put_Line (Record_Type'Component_Name (R) & " => "
Record_Type'Component_Image (R));
      end loop;
   end Put_Line;

It might be nice if the language defined a default 'Image for
composites that could be overridden, e.g.

function array_type_definition'Image return String;

   Example
   =======
   type My_Array is array ...;
   for array_type_definition'Image use To_String;

   function To_String (D : My_Array) return String;


function record_type_definition'Image return String;

   Example
   =======
   type My_Record is record ...;
   for My_Record'Image use To_String;

   function To_String (R : My_Record) return String;

Anyone think something like this has legs?

Cheers
-- Martin

Re: 'Image for composite types

[Robert A Duff]

Martin <martin.dowie@btopenworld.com> writes:

> Is it just me that gets fed up with the lack of 'Image on composite
> types?

No, it's not just you.

- Bob

Re: 'Image for composite types

[Adam Beneschan]

On May 27, 3:20 pm, Martin <martin.do...@btopenworld.com> wrote:
> Is it just me that gets fed up with the lack of 'Image on composite
> types?
>
> I'm thinking in particular of when I'm testing / debugging and usually
> end up writing lots of 'Put_Line' code for each and every record. And
> then having to maintain them.
>
> It got me thinking that the language could be expanded to include some
> helper attributes for easily composing a function that could return a
> String a la 'Image for scalar types.
>
>    function record_type_definition'Component_Name (I : Positive)
> return String;
>    function record_type_definition'Component_Image (I : Positive)
> return String;
>    function record_type_definition'Number_Of_Components return
> Natural;

This wouldn't work on variant records.  Plus, what does
'Component_Image return if the component type is itself another
record, or an array, or a task?  Or an access?

Plus, in your example below, one of your components is an
Unbounded_String, which is a private type most likely implemented as a
record or access type.  What language rule would make 'Component_Image
of that type return the string value, while 'Component_Image of other
records or access types would do something more pedestrian?

A lot more thought would have to go into this to make it a real
language feature.  Others may have opinions on whether the amount of
effort required to design this feature well, combined with the amount
of effort required for compiler vendors to implement it, is justified
by the benefits.

                                    -- Adam


>    Example
>    =======
>       type Person is
>          record
>             Name   : Unbounded_String;
>             Age    : Natural;
>             Height : Float;
>             Weight : Float;
>          end record;

Re: 'Image for composite types

[Martin]

Adam,

Thanks for the comments so far...hopefully there are answers to them
that satisfy...

On May 28, 12:44 am, Adam Beneschan <a...@irvine.com> wrote:
[snip]
> This wouldn't work on variant records.

Could add these as well?

   function record_type_definition'Discriminant_Name (I : Positive)
return String;
   function record_type_definition'Discriminant_Image (I : Positive)
return String;
   function record_type_definition'Number_Of_Discriminants return
Natural;

For 'plain' records 'Number_Of_Discriminants would return 0.


> Plus, what does
> 'Component_Image return if the component type is itself another
> record, or an array, or a task?  Or an access?

Then it would call the 'Image for that component - in the same way as
for Integer or Float etc.

> Plus, in your example below, one of your components is an
> Unbounded_String, which is a private type most likely implemented as a
> record or access type.  What language rule would make 'Component_Image
> of that type return the string value, while 'Component_Image of other
> records or access types would do something more pedestrian?

In this new extension I'm imagining that all records have at least a
compiler generated 'Image (which the user can override) with:

   type My_Record is private;
private;
   fnunction To_String (R : My_Record) return String;
   for My_Record'Image use To_String;

For access types, if I'm writing these by hand, I'd return string
"null" or call the 'Image for the component if it isn't null.


> A lot more thought would have to go into this to make it a real
> language feature.

Absolutely! That's why I'm floating the idea here rather than on Ada-
Comment.

> Others may have opinions on whether the amount of
> effort required to design this feature well, combined with the amount
> of effort required for compiler vendors to implement it, is justified
> by the benefits.

Very true. But I'm pleased to see at least 1 ARG member publicly
acknowledging the problem, if not my proposed solution.

Cheers
-- Martin

Re: 'Image for composite types

[Georg Bauhaus]

Adam Beneschan schrieb:
> On May 27, 3:20 pm, Martin <martin.do...@btopenworld.com> wrote:
>> Is it just me that gets fed up with the lack of 'Image on composite
>> types?
>>
>> I'm thinking in particular of when I'm testing / debugging and usually
>> end up writing lots of 'Put_Line' code for each and every record. And
>> then having to maintain them.


> A lot more thought would have to go into this to make it a real
> language feature.

Maybe a simple standardized package will do, as follows.
Alluding to SNOBOL-4's &TRACE mechanism, Perl's
Data::Dumper, (SML/NJ compiler access in user programs?),
and ASIS:  Since an Ada compiler knows the internal represenation
for every type, it can instantiate a simple tracing procedure.

This assumes that a stupid implementation defined subprogram
is enough for testing / debugging.

package Mypack is

   type T is private;

private

   type T is record
      U: Unbounded_String;
      T: Time;
   end record;

   pragma Convention(ASIS, T);
	-- if it is necessary to annouce this to
	-- the compiler for tracing

end Mypack;



with Compiler; -- a portable/language defined spec
with Mylog;    -- here is where I want the data images

pragma Tracing (On);

package body Mypack is

   procedure Put_T is
      new Compiler.Trace (Data => T,
                          Stream => Mylog.Stderr);

end Mypack;

Re: 'Image for composite types

[Martin]

On May 28, 10:53 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
[snip]
> This assumes that a stupid implementation defined subprogram
> is enough for testing / debugging.

I'm greedy...I want to override any stupid implementation defined
subprogram with my fancy one! (perhaps one for XML output, another for
csv, etc depending on the what I need the output for).

Cheers
-- Martin

Re: 'Image for composite types

[Georg Bauhaus]

Martin schrieb:
> On May 28, 10:53 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
> [snip]
>> This assumes that a stupid implementation defined subprogram
>> is enough for testing / debugging.
> 
> I'm greedy...I want to override any stupid implementation defined
> subprogram with my fancy one! (perhaps one for XML output, another for
> csv, etc depending on the what I need the output for).

Would filters or transformers be enough?  If output of the
compiler generated stream writer (perhaps respecting 'Output
of components) is formatted preditably, the output can be input
to a log inspection tool. The tool then produces the final output
formatted as desired without an effect on the original program.

(Maybe the transormation can be done running the circuits
of Ada.Tags.Generic_Dispatching_Constructor.
Resorting to a dummy tracing tag when there isn't a tag
for the type to be output.)

Re: 'Image for composite types

[Jeffrey R. Carter]

Martin wrote:
> 
> I'm greedy...I want to override any stupid implementation defined
> subprogram with my fancy one! (perhaps one for XML output, another for
> csv, etc depending on the what I need the output for).

Let's see ... 1st, Martin asks for 'Image for composite types. 'Image is a 
"stupid" attribute function for numeric and enumeration types. Then, when 
someone provides a mechanism by which he could obtain such a thing, he says he 
doesn't want 'Image for composite types unless he can do things with it that he 
can't do with the existing 'Image. Sounds a bit like the kind of thing Babbage 
complained about:

"Propose to an Englishman any principle, or any instrument, however
admirable, and you will observe that the whole effort of the English
mind is directed to find a difficulty, a defect, or an impossibility
in it. If you speak to him of a machine for peeling a potato, he will
pronounce it impossible: if you peel a potato with it before his eyes,
he will declare it useless, because it will not slice a pineapple."
Charles Babbage

-- 
Jeff Carter
"What lazy lout left these wires all over the lawn?"
Poppy
98

Re: 'Image for composite types

[Martin]

On May 28, 5:25 pm, "Jeffrey R. Carter"
<spam.jrcarter....@nospam.acm.org> wrote:
> Martin wrote:
>
> > I'm greedy...I want to override any stupid implementation defined
> > subprogram with my fancy one! (perhaps one for XML output, another for
> > csv, etc depending on the what I need the output for).
>
> Let's see ... 1st, Martin asks for 'Image for composite types. 'Image is a
> "stupid" attribute function for numeric and enumeration types. Then, when
> someone provides a mechanism by which he could obtain such a thing, he says he
> doesn't want 'Image for composite types unless he can do things with it that he
> can't do with the existing 'Image. Sounds a bit like the kind of thing Babbage
> complained about:
>
> "Propose to an Englishman any principle, or any instrument, however
> admirable, and you will observe that the whole effort of the English
> mind is directed to find a difficulty, a defect, or an impossibility
> in it. If you speak to him of a machine for peeling a potato, he will
> pronounce it impossible: if you peel a potato with it before his eyes,
> he will declare it useless, because it will not slice a pineapple."
> Charles Babbage

But I _am_ asking for something different to the existing 'Image - the
ability to override it with whatever I want 'Image to produce. For
some values a 16#...# might be more appropriate than the default
string.

There would seem to be little pointing add this for composite types
and not scalar ones too.

Cheers
-- Martin

p.s. you can call me anything your like...just please never, EVER
English! ;-)

Re: 'Image for composite types

[Per Sandberg]

Have a look on:
   http://www.stephe-leake.org/ada/auto_text_io.html
I don know the exact state of it but it may help.
/Per


Martin wrote:
> Is it just me that gets fed up with the lack of 'Image on composite
> types?
> 
> I'm thinking in particular of when I'm testing / debugging and usually
> end up writing lots of 'Put_Line' code for each and every record. And
> then having to maintain them.
> 
> It got me thinking that the language could be expanded to include some
> helper attributes for easily composing a function that could return a
> String a la 'Image for scalar types.
> 
>    function record_type_definition'Component_Name (I : Positive)
> return String;
>    function record_type_definition'Component_Image (I : Positive)
> return String;
>    function record_type_definition'Number_Of_Components return
> Natural;
> 
>    Example
>    =======
>       type Person is
>          record
>             Name   : Unbounded_String;
>             Age    : Natural;
>             Height : Float;
>             Weight : Float;
>          end record;
>    ...
>       procedure Put_Line (P : Person) is
>       begin
>          Put_Line (P.Name);
>          for I in 2 .. Person'Number_Of_Components (P) loop
>             Put_Line (Person'Component_Name (I) & " => " &
> Person'Component_Image (I));
>          end loop;
>       end Put_Line;
>    ...
>       Me : Person := (Name   => To_Unbounded_String ("Martin"),
>                       Age    => 40,
>                       Height => 1.70,
>                       Weight => 82.5);
>    begin
>       Put_Line (Me);
>    ...
> 
> Gives output:
> Martin
> Age => 40
> Height => 1.70
> Weight => 82.5
> 
> 
> Or I could define a generic procedure for any of my record types, e.g.
> 
>    generic
>       type Record_Type is private;
>    procedure Put_Line (R : Record_Type);
> 
>    procedure Put_Line (R : Record_Type) is
>    begin
>       -- Notice: no actual names are used at all...
>       for R in 1 .. Record_Type'Number_Of_Components loop
>          Put_Line (Record_Type'Component_Name (R) & " => "
> Record_Type'Component_Image (R));
>       end loop;
>    end Put_Line;
> 
> It might be nice if the language defined a default 'Image for
> composites that could be overridden, e.g.
> 
> function array_type_definition'Image return String;
> 
>    Example
>    =======
>    type My_Array is array ...;
>    for array_type_definition'Image use To_String;
> 
>    function To_String (D : My_Array) return String;
> 
> 
> function record_type_definition'Image return String;
> 
>    Example
>    =======
>    type My_Record is record ...;
>    for My_Record'Image use To_String;
> 
>    function To_String (R : My_Record) return String;
> 
> Anyone think something like this has legs?
> 
> Cheers
> -- Martin

Re: 'Image for composite types

[tmoran]

> Is it just me that gets fed up with the lack of 'Image on composite
> types?
  Could you use the S'Output stream mechanism?  Declare your new
Ada.Streams.Root_Stream_Type with a Write that writes as a text string to
a log file, and your own elementary Integer'Write, Boolean'Write etc and
let the stream mechanism generate a concatenation of components for
composite types.  Of course you would have to add a mechanism for line
breaks or the output would be a continuous string of numbers, enumeration
literals, and so forth, but you would need that also if there was a
language defined 'Image.

Re: 'Image for composite types

[Martin]

On May 28, 4:36 am, Per Sandberg <per.sandb...@bredband.net> wrote:
> Have a look on:
>    http://www.stephe-leake.org/ada/auto_text_io.html
> I don know the exact state of it but it may help.
> /Per

Thanks for the link.

Cheers
-- Martin

Re: 'Image for composite types

[Dmitry A. Kazakov]

On Wed, 27 May 2009 15:20:56 -0700 (PDT), Martin wrote:

> Is it just me that gets fed up with the lack of 'Image on composite
> types?

That 'Image is not a primitive operation is even worse.

> It got me thinking that the language could be expanded to include some
> helper attributes for easily composing a function that could return a
> String a la 'Image for scalar types.
> 
>    function record_type_definition'Component_Name (I : Positive)
> return String;
>    function record_type_definition'Component_Image (I : Positive)
> return String;
>    function record_type_definition'Number_Of_Components return
> Natural;

This is the interface of a container type. A right solution should make all
records inherit from an abstract ordered mapping, so these primitive
operations will be for free.

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

Re: 'Image for composite types

[Stephen Leake]

Martin <martin.dowie@btopenworld.com> writes:

> Is it just me that gets fed up with the lack of 'Image on composite
> types?
>
> I'm thinking in particular of when I'm testing / debugging and usually
> end up writing lots of 'Put_Line' code for each and every record. And
> then having to maintain them.

That's what Auto_Text_IO is for
http://www.stephe-leake.org/ada/auto_text_io.html 

> It got me thinking that the language could be expanded to include some
> helper attributes for easily composing a function that could return a
> String a la 'Image for scalar types.

I should think the compiler could just compose 'Image for each
component.

That won't work for access types, or task types (and probably others);
there would have to be a way to provide user functions for those; a
defineable 'Image attribute would be good, as you propose.

-- 
-- Stephe

Re: 'Image for composite types

[Martin]

On May 31, 1:17 pm, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Martin <martin.do...@btopenworld.com> writes:
> > Is it just me that gets fed up with the lack of 'Image on composite
> > types?
>
> > I'm thinking in particular of when I'm testing / debugging and usually
> > end up writing lots of 'Put_Line' code for each and every record. And
> > then having to maintain them.
>
> That's what Auto_Text_IO is forhttp://www.stephe-leake.org/ada/auto_text_io.html
>
> > It got me thinking that the language could be expanded to include some
> > helper attributes for easily composing a function that could return a
> > String a la 'Image for scalar types.
>
> I should think the compiler could just compose 'Image for each
> component.
>
> That won't work for access types, or task types (and probably others);
> there would have to be a way to provide user functions for those; a
> defineable 'Image attribute would be good, as you propose.
>
> --
> -- Stephe

Thanks for the link - just wish it was part of the language, make life
even easier.

Cheers
-- Martin