Re: Parser interface design

[Simon Wright <simon@pushface.org>]

Natasha Kerensikova <lithiumcat@gmail.com> 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?

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?

> 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!

> 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?

Personally I tend to feel uneasy with access-to-subprogram.

> All in all, I can't find any argument in favor of replacing the record
> of accesses with the generic approach.

Nor can I.


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?