Re: Parser interface design

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 7 Apr 2011 19:44:22 +0000 (UTC), Natasha Kerensikova wrote:

> The direct transposition of my C implementation would be something like
> 
>    type Renderer_Callbacks is record
>       Emphasis:    access function (Contents: String) return String;
>       Normal_Text: access function (Contents: String) return String;
>       Paragraph:   access function (Contents: String) return String;
>    end record;
> 
>    function Parser (Renderer: Renderer_Callbacks; Input: String)
>      return String;

An OO approach:

   type Abstract_Context is abstract
       new Ada.Finalization.Limited_Controlled with private;
   procedure On_Emphasis
             (  Context : in out Abstract_Context;
                Token   : String
             )  is null;
   ...

   type Abstract_Source is abstract ...;
   function Get_Next_Line (Source : in out Abstract_Source)
       return String is abstract;
   ...

   type Parser is ... -- Abstract if many parsing methods to coexist
   procedure Parse
             (  Object  : in out Parser;
                Source  : in out Abstract_Source'Class;
                Context : in out Abstract_Context'Class
             );

or using mix-in:

   type Parser
        (  Source  : not null access Abstract_Source'Class;
           Context : not null access Abstract_Context'Class
        )  is ...; 
   procedure Parse (Object : in out Parser);

A renderer may directly implement Abstract_Context, but usually one makes
it mix-in in order to have an ability for many different renderers to have
a hierarchy of their own independently on any parsing issues. This is what
I suppose Georg's example of Print procedure should illustrate.

[ Abstract_Context may render, generate AST, interperet. Abstract_Source
may encapsulate a text file, text stream, string, XML-ish garbage etc. ]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de