Re: Indefinite type while writing a recursive descent parser

[Victor Porton <porton@narod.ru>]

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