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!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!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: Fri, 8 Apr 2011 14:03:07 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <4d9c8c19$0$6769$9b4e6d93@newsspool3.arcor-online.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Fri, 8 Apr 2011 14:03:07 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="2978"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/6SxfgHoxQCrHyRRVx0HsF" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:ZfFfxCk1mIZisswqVkR0uOaIf9k= Xref: g2news2.google.com comp.lang.ada:19693 Date: 2011-04-08T14:03:07+00:00 List-Id: Hello, On 2011-04-07, Simon Wright wrote: > Natasha Kerensikova writes: > >> Now at least I understand the idea of using generics instead: >> >> generic >> with function Emphasis (Contents: String) return String is <>; >> with function Normal_Text (Contents: String) return String is <>; >> with function Paragraph (Contents: String) return String is <>; >> function Parser (Renderer: Renderer_Callbacks; Input: String) >> return String; > > I think the Renderer argument shouldn't be there? Yes, it's a mistake caused by a too hasty cut'n'paste too late in the evening. My bad. > Don't see what's wrong with providing a No_Op function which returns its > input unchanged? unless you do something specific for a null? Yes, as I said in my reply to Dmitry, I thought of disabling in the parser the feature associated to a callback set to null. In the "foo *bar* baz" example I provided, using a No_Op for Emphasis would result in "

foo baz

", while disabling the emphasis feature means considering the star as an inactive character, resulting in "

foo *bar* baz

". >> However I am a bit skeptical about whether or not generics is actually a >> better approach than the record of accesses. Generics is certainly a >> higher-level feature than record and access, but I don't think that's >> enough to prefer one over the other. On the other hand, I understand the >> criticism of generics posted here (with my apologies for not remember >> who had which arguments), with all the problems caused by the function >> not actually existing until it's instanced. > > Not sure I remember that, generics aren't _that_ bad! Well, maybe my lack of understanding of Ada made me draw conclusions that are much too machinean than warranted - I have seen it happen too often with journalist to imagine I couldn't fall in the same trap. >> I believe such generics to be a lesser evil than generic types, and >> similarly I believe access to subprograms to be lesser evils than access >> to data. However I wouldn't be surprised if parser instantiation means >> duplicating the code for each parser. Even if it's the compiler that >> actually performs the code duplication, I'm not very at ease with it. > > I'd let it get on with it. You're unlikely to have many instantiations > in one program, I'd have thought? Well, the example from my C implementation used 6 renderers, selectable through command-line flags. That would mean 6 instantiations in an Ada equivalent. Granted, it's not that "many". > Personally I tend to feel uneasy with access-to-subprogram. Maybe my extensive of C pointers, to subprograms or data alike, made me more at ease with accesses than Ada alone warrants. >> All in all, I can't find any argument in favor of replacing the record >> of accesses with the generic approach. > > Nor can I. Great :-) But now I find my arguments for replacing generics with a record of accesses quite weak too. Could it be that none of them is extremely better than the other? > In your original post, you said > >> I also though of implementing each callback once, as standalone >> procedures, and then use tagged procedures to call them, but that >> seems very messy too. > > Presumably you'll implement each callback once, as a standalone function, > and pop them in the record/call the generic as appropriate? Yes, that is fulfilled with both the record and the generic approaches. However for example when the renderer is a tagged object, I can't see how to avoid ending up with "methods" that are nothing but wrapper around a real (shared) callback. Thanks for your help, Natasha