* 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