Re: Parser interface design

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

On Fri, 8 Apr 2011 13:51:51 +0000 (UTC), Natasha Kerensikova wrote:

>>> I'm asking
>>> because in my C implementation, a NULL callback was a meant to
>>> communicate to the parser that the associated active character should
>>> no longer be considered active, thereby switching off that particular
>>> feature (which is very different from having a no-op callback).
>>
>> Why should you test for anything? Just make the implementation do what is
>> required to do in order to achieve the desired effect.
> 
> Well, that test thing is an implementation detail, on which I believe is
> too early to spend time.

No, it is not an implementation, because the check happens on the caller's
side. Implementation detail is always a callee's thing .

> Then, it so happens that the set of features matches exactly the set of
> callbacks.

If the property is one of the callback, it is the callback's responsibility
to check it. Moving it to the parser is fragile design.

> I just can't imagine any design that has a use of several hierarchy, for
> now. (when writing the OP I could imagine only one design, and now I've
> already reached two designs, sketched above, so I'm progressing)

When your parser sums two numbers it does not have + as a primitive
operation. Does it? If numbers may have a hierarchy of their own, why
renderer cannot? 

> As long as the design is the client calling exactly once the parser,
> there is no need for an object to keep a hidden state, the local stack
> is enough, isn't it?

Maybe. Note that more states you glue together by maintaining single
hierarchy of "everything", more difficult it becomes for single stack. BTW,
parsing infix expressions is much simpler with two stacks. You might also
wish not to use the standard stack for such things.
 
> but as far as I can tell, parser or coordinator objects don't
> need to be tagged or in any hierarchy, or am I missing something?

You never know it in advance. It depends on the parser design. A
table-driven parser might be extended rather by extending the tables it
uses. Other parsers might be extended directly.

In Ada you lose nothing making it tagged. Differently to C++ where
"virtual" has non-zero overhead, in Ada making a procedure primitive has
zero performance cost, because the target will be resolved statically.

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