comp.lang.ada
 help / color / mirror / Atom feed
* A trouble with different instantiations of generic packages
@ 2017-11-28 23:22 Victor Porton
  2017-11-29  1:13 ` Victor Porton
  0 siblings, 1 reply; 3+ messages in thread
From: Victor Porton @ 2017-11-28 23:22 UTC (permalink / raw)


This problem appears when I try to "parse" (that is analyze like an abstract
syntax tree) an RDF directed graph. I think similar problem would appear with
a regular file parser.

I realize that I described the problem domain not very clearly, but I ask a
general question about generic packages, not about parsers specifically.

I have the following basic generic packages:

   -- Parser for subnodes (identified by Predicate) of Node
   generic
      type Data_Type (<>) is private;
   package Base_Predicate is

      type Base_Predicate_Parser is abstract tagged limited
         record
            Predicate: URI_Type;
         end record;

      not overriding function Parse (Context: Parser_Context_Type'Class;
                                     Parser: Base_Predicate_Parser;
                                     Model: Model_Type_Without_Finalize'Class;
                                     Node: Node_Type_Without_Finalize'Class)
                                     return Data_Type
                                     is abstract;

   end Base_Predicate;

   -- Parser for a node
   generic
      type Data_Type (<>) is private;
   package Base_Node is

      type Base_Node_Parser is abstract tagged limited
         null record;

      not overriding function Parse (Context: Parser_Context_Type'Class;
                                     Parser: Base_Node_Parser;
                                     Model: Model_Type_Without_Finalize'Class;
                                     Node: Node_Type_Without_Finalize'Class)
                                     return Data_Type
                                     is abstract;

   end Base_Node;

   -- Parser which ensures a node has exactly one subnode (for Predicate)
   generic
      type Child_Type (<>) is private;
   package One_Predicate is
      package Node_Parser is new Base_Node(Child_Type);
      package Predicate_Parser is new Base_Predicate(Child_Type);
      type One_Predicate_Parser is new Predicate_Parser.Base_Predicate_Parser with
         record
            Child_Parser: access Node_Parser.Base_Node_Parser'Class;
         end record;
      overriding function Parse (Context: Parser_Context_Type'Class;
                                 Parser: One_Predicate_Parser;
                                 Model: Model_Type_Without_Finalize'Class;
                                 Node: Node_Type_Without_Finalize'Class)
                                 return Child_Type;
   end One_Predicate;

Then I derive a specific parser like this:

   package Float_Node is new Base_Node(Long_Float);

   type Float_Literal_Parser is new Float_Node.Base_Node_Parser with null record;

   overriding function Parse (Context: Parser_Context_Type'Class;
                              Parser: Float_Literal_Parser;
                              Model: Model_Type_Without_Finalize'Class;
                              Node: Node_Type_Without_Finalize'Class)
                              return Long_Float;

But when I try to create an object of type One_Predicate_Parser with
Float_Literal_Parser child access, it fails because
Float_Node.Base_Node_Parser is not the same (a different instantiation) as
One_Predicate.Node_Parser.Base_Node_Parser.

What to do?

Maybe I should use in One_Predicate a package formal generic parameter like:

   package Node_Parser is new Base_Node(Child_Type);

?

Are there better ways?

-- 
Victor Porton - http://portonvictor.org


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: A trouble with different instantiations of generic packages
  2017-11-28 23:22 A trouble with different instantiations of generic packages Victor Porton
@ 2017-11-29  1:13 ` Victor Porton
  2017-11-29  9:04   ` Dmitry A. Kazakov
  0 siblings, 1 reply; 3+ messages in thread
From: Victor Porton @ 2017-11-29  1:13 UTC (permalink / raw)


Yes, to use formal generic packages seems a solution.

Victor Porton wrote:
> This problem appears when I try to "parse" (that is analyze like an
> abstract syntax tree) an RDF directed graph. I think similar problem would
> appear with a regular file parser.
> 
> I realize that I described the problem domain not very clearly, but I ask
> a general question about generic packages, not about parsers specifically.
> 
> I have the following basic generic packages:
> 
>    -- Parser for subnodes (identified by Predicate) of Node
>    generic
>       type Data_Type (<>) is private;
>    package Base_Predicate is
> 
>       type Base_Predicate_Parser is abstract tagged limited
>          record
>             Predicate: URI_Type;
>          end record;
> 
>       not overriding function Parse (Context: Parser_Context_Type'Class;
>                                      Parser: Base_Predicate_Parser;
>                                      Model:
>                                      Model_Type_Without_Finalize'Class;
>                                      Node:
>                                      Node_Type_Without_Finalize'Class)
>                                      return Data_Type is abstract;
> 
>    end Base_Predicate;
> 
>    -- Parser for a node
>    generic
>       type Data_Type (<>) is private;
>    package Base_Node is
> 
>       type Base_Node_Parser is abstract tagged limited
>          null record;
> 
>       not overriding function Parse (Context: Parser_Context_Type'Class;
>                                      Parser: Base_Node_Parser;
>                                      Model:
>                                      Model_Type_Without_Finalize'Class;
>                                      Node:
>                                      Node_Type_Without_Finalize'Class)
>                                      return Data_Type is abstract;
> 
>    end Base_Node;
> 
>    -- Parser which ensures a node has exactly one subnode (for Predicate)
>    generic
>       type Child_Type (<>) is private;
>    package One_Predicate is
>       package Node_Parser is new Base_Node(Child_Type);
>       package Predicate_Parser is new Base_Predicate(Child_Type);
>       type One_Predicate_Parser is new
>       Predicate_Parser.Base_Predicate_Parser with
>          record
>             Child_Parser: access Node_Parser.Base_Node_Parser'Class;
>          end record;
>       overriding function Parse (Context: Parser_Context_Type'Class;
>                                  Parser: One_Predicate_Parser;
>                                  Model: Model_Type_Without_Finalize'Class;
>                                  Node: Node_Type_Without_Finalize'Class)
>                                  return Child_Type;
>    end One_Predicate;
> 
> Then I derive a specific parser like this:
> 
>    package Float_Node is new Base_Node(Long_Float);
> 
>    type Float_Literal_Parser is new Float_Node.Base_Node_Parser with null
>    record;
> 
>    overriding function Parse (Context: Parser_Context_Type'Class;
>                               Parser: Float_Literal_Parser;
>                               Model: Model_Type_Without_Finalize'Class;
>                               Node: Node_Type_Without_Finalize'Class)
>                               return Long_Float;
> 
> But when I try to create an object of type One_Predicate_Parser with
> Float_Literal_Parser child access, it fails because
> Float_Node.Base_Node_Parser is not the same (a different instantiation) as
> One_Predicate.Node_Parser.Base_Node_Parser.
> 
> What to do?
> 
> Maybe I should use in One_Predicate a package formal generic parameter
> like:
> 
>    package Node_Parser is new Base_Node(Child_Type);
> 
> ?
> 
> Are there better ways?
> 
-- 
Victor Porton - http://portonvictor.org


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: A trouble with different instantiations of generic packages
  2017-11-29  1:13 ` Victor Porton
@ 2017-11-29  9:04   ` Dmitry A. Kazakov
  0 siblings, 0 replies; 3+ messages in thread
From: Dmitry A. Kazakov @ 2017-11-29  9:04 UTC (permalink / raw)


On 29/11/2017 02:13, Victor Porton wrote:
> Yes, to use formal generic packages seems a solution.

Or to use generic children packages:

    generic
       type T is ...;
    package A is
       ...
    end A;

    generic
    package A.B is ... -- This one goes with the same T
       ...
    end A.B;

These are two competing approaches.

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-11-29  9:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-28 23:22 A trouble with different instantiations of generic packages Victor Porton
2017-11-29  1:13 ` Victor Porton
2017-11-29  9:04   ` Dmitry A. Kazakov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox