Re: Parser interface design

[Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>]

On 04/08/2011 07:03 AM, Natasha Kerensikova wrote:
>
> Yes, as I said in my reply to Dmitry, I thought of disabling in the
> parser the feature associated to a callback set to null. In the
> "foo *bar* baz" example I provided, using a No_Op for Emphasis would
> result in "<p>foo  baz</p>", while disabling the emphasis feature means
> considering the star as an inactive character, resulting in
> "<p>foo *bar* baz</p>".

Without knowing much about your domain, I'd think

type Parse_Result_Info is ...;

generic -- Parse
    with procedure Render (Parse_Result : in Parse_Result_Info);
procedure Parse (...);

would provide you with this kind of discrimination. A Render that does something 
for the '*' construct would recognize it and take the desired action, while a 
Render that doesn't would give the results you want. Another advantage is that 
you have no limit on the number of constructs that you can handle, rather than 
the fixed number required when using a separate subprogram for each construct.

The limitation here seems to be that Parse is going to parse according to a 
fixed grammar. Perhaps it could be given a grammar as a parameter to make it 
more flexible, or it may be possible to provide more generic formal parameters 
that define how it parses.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67