Indefinite type while writing a recursive descent parser

Indefinite type while writing a recursive descent parser

[Victor Porton]

I am writing a recursive descent parser. (It parses RDF relations rather 
than a text file, but that's not very important for my question, except for 
the fact that I cannot use an existing text parser package.)

While parsing I need to extract data (numbers, booleans, arrays, etc.)

My first idea was:

generic
   type Data_Type(<>) is private;
package Base_Predicate is
   type Base_Predicate_Parser is tagged
      record
         Predicate: URI_Type;
         Data: access Data_Type;
      end record;
   not overriding
   procedure Parse (Parser: Base_Predicate_Parser; Node: Node_Type) is null;
end Base_Predicate;

I wanted my node parsers to assign to Data.all if Data/=null.

But then I realized that this won't work for an indefinite Data_Type.

So I have an Ada (2012) specific issue on possible ways to assign data while 
parsing. Please give advice.

I could use Indefinite_Holders everywhere but this would be a step into the 
direction of being like a dynamic language instead of strong typing system 
which Ada offers. I don't like to make a step in this direction.

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

Re: Indefinite type while writing a recursive descent parser

[Victor Porton]

Victor Porton wrote:

> I am writing a recursive descent parser. (It parses RDF relations rather
> than a text file, but that's not very important for my question, except
> for the fact that I cannot use an existing text parser package.)
> 
> While parsing I need to extract data (numbers, booleans, arrays, etc.)
> 
> My first idea was:
> 
> generic
>    type Data_Type(<>) is private;
> package Base_Predicate is
>    type Base_Predicate_Parser is tagged
>       record
>          Predicate: URI_Type;
>          Data: access Data_Type;
>       end record;
>    not overriding
>    procedure Parse (Parser: Base_Predicate_Parser; Node: Node_Type) is
>    null;
> end Base_Predicate;
> 
> I wanted my node parsers to assign to Data.all if Data/=null.
> 
> But then I realized that this won't work for an indefinite Data_Type.
> 
> So I have an Ada (2012) specific issue on possible ways to assign data
> while parsing. Please give advice.
> 
> I could use Indefinite_Holders everywhere but this would be a step into
> the direction of being like a dynamic language instead of strong typing
> system which Ada offers. I don't like to make a step in this direction.

It seems for me the right idea to:

- restrict Data_Type only to definite types as a record member where we are 
to store the data is anyway not supporting indefinite types

- whenever we need an indefinite type, replace it with an indefinite holder 
defined specifically for this type

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

Re: Indefinite type while writing a recursive descent parser

[Victor Porton]

Victor Porton wrote:

> Victor Porton wrote:
> 
>> I am writing a recursive descent parser. (It parses RDF relations rather
>> than a text file, but that's not very important for my question, except
>> for the fact that I cannot use an existing text parser package.)
>> 
>> While parsing I need to extract data (numbers, booleans, arrays, etc.)
>> 
>> My first idea was:
>> 
>> generic
>>    type Data_Type(<>) is private;
>> package Base_Predicate is
>>    type Base_Predicate_Parser is tagged
>>       record
>>          Predicate: URI_Type;
>>          Data: access Data_Type;
>>       end record;
>>    not overriding
>>    procedure Parse (Parser: Base_Predicate_Parser; Node: Node_Type) is
>>    null;
>> end Base_Predicate;
>> 
>> I wanted my node parsers to assign to Data.all if Data/=null.
>> 
>> But then I realized that this won't work for an indefinite Data_Type.
>> 
>> So I have an Ada (2012) specific issue on possible ways to assign data
>> while parsing. Please give advice.
>> 
>> I could use Indefinite_Holders everywhere but this would be a step into
>> the direction of being like a dynamic language instead of strong typing
>> system which Ada offers. I don't like to make a step in this direction.
> 
> It seems for me the right idea to:
> 
> - restrict Data_Type only to definite types as a record member where we
> are to store the data is anyway not supporting indefinite types
> 
> - whenever we need an indefinite type, replace it with an indefinite
> holder defined specifically for this type

However, this seems a suboptimal solution for lists of indefinite objects: 
this way of work would lead to a definite vector of indefinite holders 
rather than to indefinite vector of indefinite objects.

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

Re: Indefinite type while writing a recursive descent parser

[Victor Porton]

Victor Porton wrote:

> Victor Porton wrote:
> 
>> Victor Porton wrote:
>> 
>>> I am writing a recursive descent parser. (It parses RDF relations rather
>>> than a text file, but that's not very important for my question, except
>>> for the fact that I cannot use an existing text parser package.)
>>> 
>>> While parsing I need to extract data (numbers, booleans, arrays, etc.)
>>> 
>>> My first idea was:
>>> 
>>> generic
>>>    type Data_Type(<>) is private;
>>> package Base_Predicate is
>>>    type Base_Predicate_Parser is tagged
>>>       record
>>>          Predicate: URI_Type;
>>>          Data: access Data_Type;
>>>       end record;
>>>    not overriding
>>>    procedure Parse (Parser: Base_Predicate_Parser; Node: Node_Type) is
>>>    null;
>>> end Base_Predicate;
>>> 
>>> I wanted my node parsers to assign to Data.all if Data/=null.
>>> 
>>> But then I realized that this won't work for an indefinite Data_Type.
>>> 
>>> So I have an Ada (2012) specific issue on possible ways to assign data
>>> while parsing. Please give advice.
>>> 
>>> I could use Indefinite_Holders everywhere but this would be a step into
>>> the direction of being like a dynamic language instead of strong typing
>>> system which Ada offers. I don't like to make a step in this direction.
>> 
>> It seems for me the right idea to:
>> 
>> - restrict Data_Type only to definite types as a record member where we
>> are to store the data is anyway not supporting indefinite types
>> 
>> - whenever we need an indefinite type, replace it with an indefinite
>> holder defined specifically for this type
> 
> However, this seems a suboptimal solution for lists of indefinite objects:
> this way of work would lead to a definite vector of indefinite holders
> rather than to indefinite vector of indefinite objects.

Oh, it seems I know what to do:

When parsing data into a vector, for each element first parse into an 
indefinite holder and then add a copy of it to the end of the (indefinite) 
vector.

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