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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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: g2news2.google.com!news4.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Parser interface design Date: Tue, 12 Apr 2011 15:58:04 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1p6q05xtgjspf.7qanu7wlynvi$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Tue, 12 Apr 2011 15:58:04 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="2205"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19WAeqNll3uhUyygeAPM8KZ" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:dA1CK5WFnv2vKngs025w68D+SQk= Xref: g2news2.google.com comp.lang.ada:19741 Date: 2011-04-12T15:58:04+00:00 List-Id: Hello, On 2011-04-08, Dmitry A. Kazakov wrote: > 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 . I'm afraid we might not talking about the same "implementation" here, I might have misused the word. Your "implementation" is the "callback implementation" (callee) which indeed has nothing to do with the parser (caller), that's the hole point of distinguishing *specification* and implementation. My "implementation" is the "parser implementation", that is whether to use a NULL callback as an input parameter to disable the feature associated to the callback. That would actually be reflected in the parser specification, but there I used the word "implementation" as opposed to "design", which is the current phase. I believe it's premature to discuss how the client should specify which Markdown features to enable or disable in the parser, when how the client and the parser will communicate is not even decided yet. That's why I meant by "that test thing is an implementation detail". >> 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. In such a case, there would be no callback at all. >> 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? 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. Still, I can't imagine how to compartmentalize that whole Markdown pipeline in such a way that I would need several class hierarchies. >> 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. There I'm completely lost. I didn't have the impression of gluing several states together in my first design. 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? > 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? It seems to boil down to a matter of extensibility. In that particular case, I can't see any way of designing the parser in a way that it can be extended into one of the few Markdown extensions I know. So I've considered the parser to be basically non-extensible, meant only to be re-used as is. Is it an intrinsically bad design, or can it be an acceptable compromise? Thanks for your comments, Natasha