Re: Parser interface design

[Brian Drummond <brian@shapes.demon.co.uk>]

On Wed, 06 Apr 2011 10:11:46 +0000, Natasha Kerensikova wrote:

> Hello,
> 
> before wasting too much time of anybody, I want to make it clear that
> I'm asking about interface design in Ada which might actually never turn
> up into real code. I'm still unsure about ever writing Ada code, and how
> bad my previous thread went playing no small part in that. However I'm
> still curious about how this particular problem might be solved in Ada.
> 
> I wrote a while back a C library to parse Markdown text. I call "parser"
> the code that takes a text assumed to be formatted in Markdown as input,
> and communicates in a still-to-be-defined way with another component,
> which I call "renderer", and which outputs the same text but using
> another formatting, for example HTML or PDF.
> 
> The problem on which I want your opinion is designing the interface
> between the parser and the renderer. The point is to be able to "plug"
> may renderer into the parser, and thereby obtain a different kind of
> output, with as little code rewrite as possible (hence the idea of
> refactoring the "parser" into a re-usable part).

One approach to the renderer : streaming I/O.

I don't know if it's the right approach for your problem, but Ada's 
stream I/O is flexible and capable of interesting things.

Ada.Streams allows you to overload your own Read and Write procedures for 
existing types, and define them for new types.

I have played with this a little, though not for your specific purpose.

It looks as if it ought to be possible to create PDF_Stream, HTML_Stream, 
RTF_Stream etc and output to any or all of them.

Sketch of one possible approach, where HTML_Stream, PDF_Stream are 
derived from the root stream class somehow... 
NOt tested : this may not work for multiple types of stream.

-- expose only this to the parser
type style is (none, bold, italic);

type formatted_string is record
   format : style;
   content : bounded_string;
end record;
(Or use discriminants for arbitrary string length.
It is up to the parser to supply formatted_strings)

type element is (ruler, page_break);

-- the rest is internal to the renderer

type V_String_Array is array (style) of V_String;
-- see Barnes p.402 on v-strings and ragged arrays

html_tags : constant V_String_Array := (+"", +"<b>", ...);
html_end_tags : constant V_String_Array := (+"", +"</b>", ...);

procedure write_formatted_string (stream : HTML_Stream; 
                                  f_string : formatted_string) is
begin
   write(html_tags(f_string.format));
   write(f_string.content);
   write(html_tags(f_string.format));
end write_html_formatted_string;

procedure write__element(stream : HTML_Stream) is ...

procedure write_formatted_string (stream : PDF_Stream; 
                                  f_string : formatted_string) is ...

for formatted_string'write use write_formatted_string;
for element'write use write_element; 

(then stream I/o as normal. Possibly open the correct stream type 
according to the supplied filename extension?)

My previous experiment with streams is described at

http://groups.google.com/group/comp.lang.ada/browse_thread/
thread/9642027a78f96963/8449fae50ece601f?q=group:comp.lang.ada
+insubject:newbie+author:brian_drummond%40btconnect.com#8449fae50ece601f

Here, I was trying to use generic Write procedures to write many (two in 
the example!) different enumerations, with control over how each 
enumeration appeared over the outputs. I ran into difficulties, and had 
to use renames to overcome them.

You may have some similar difficulty overloading procedures to write  
e.g. the formatted_string to different types of stream. It may be 
possible to resolve this by instantiating generic procedures, and 
renaming, as in my example above.

- Brian