From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,50e705cdf2767cc6
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 06 Apr 2011 14:17:29 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Parser interface design
References: <slrnipof32.2fnq.lithiumcat@sigil.instinctive.eu>
In-Reply-To: <slrnipof32.2fnq.lithiumcat@sigil.instinctive.eu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4d9c59da$0$7664$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 06 Apr 2011 14:17:30 CEST
NNTP-Posting-Host: c9c9664d.newsspool1.arcor-online.net
X-Trace: 
 DXC=kYd530e`Md\U6b:FjPaGjQic==]BZ:af^4Fo<]lROoRQ<`=YMgDjhgRDb>jfmWVF0[nc\616M64>ZLh>_cHTX3j]65@_LWFH>b]
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:18693
Date: 2011-04-06T14:17:30+02:00
List-Id: <comp.lang.ada>

On 06.04.11 12:11, Natasha Kerensikova wrote:

> I can see three kinds of interfaces:
>   * an "offline" interfacing, where the parser returns an in-memory
>     abstract representation of the input, which is then processed by the
> renderer to produce its output;
>   * an "event-based" interfacing, which is basically an "online"
>     renderer-driven interfacing: the parser is first fed the input text,
> and then various functions allows to query its state, the current
> "event" (an event being "that kind of element has been encountered", or
> "the input file is over"), the event parameters, etc.
>   * a "callback-based" interfacing, which is an "online" parser-driven
>     interfacing, where the parser is provided both the input text and a
> set of callback from the renderer.

Before offering an answer to the other questions, I'd like to
throw in a fourth option:

 * use a task that serves as an event queue. The task will collect
parsing events and forward them as necessary.  The parser is then
completely ignorant of any rendering.

As there are several input formats, one might either activate the
task matching the input format, or make a task exhibit different
behavior depending on the input format.