Re: Parser interface design

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

On Tue, 12 Apr 2011 15:58:04 +0000 (UTC), Natasha Kerensikova wrote:

> On 2011-04-08, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Fri, 8 Apr 2011 13:51:51 +0000 (UTC), Natasha Kerensikova wrote:
>>> 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 don't think whether the access-to-subprogram provided to the parser
> being null or not is actually a property of the callback itself.

No, it is not. This is what makes such design fragile.

>> 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? 
> 
> I'm actually not sure what a "primitive operation" actually is. I've
> actually never heard of OOP-style class hierarchy among numbers in Ada,
> so I might be missing something big.

Nevertheless you are successfully using numbers with things which are not
numbers. Which is the point. Why a renderer cannot be used independently on
parser? At least for testing purpose?

> I didn't have the impression of gluing several states together in my
> first design.

Renderer, source/input, parser have logically independent states.
 
 I haven't never looked at infix expressions, and
> fortunately Markdown doesn't contain any. And on top of that, I'm not
> sure exactly what you are referring to with "standard stack"; is it a
> special Ada concept, or is it the standard x86 stack where function
> return information and parameters are stored?

Let's call it local stack.

>> 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.
> 
> Interesting to know. But it still makes sense to not tag types that
> don't need it, right?

No. IMO there are only three reasons why something is not tagged:

1. [premature] Optimization: tagged types are by-reference and have stored
tag.

2. Language problem: in Ada some types cannot be tagged.

3. Class-wide behavior, i.e. T'Class.

> It seems to boil down to a matter of extensibility.

Rather to the least constraint. You should not introduce constraints
without a reason.

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