Re: Starter project: getopt_long in Ada

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2011-11-27, Yannick Duchêne <yannick_duchene@yahoo.fr> wrote:
> Le Sun, 27 Nov 2011 13:30:28 +0100, Natasha Kerensikova  
><lithiumcat@gmail.com> a écrit:
>> It's just that I don't like at all having a tagged type for only one
>> dispatching operation (and no obvious need for internal state).
> If you think Specification, you should not say “I” here.

I'm sorry, but I don't understand what you mean there.

>> Of course that's only when considering related operations. In another
>> project that I will publish soon (still needs a bit of polishing), I use
>> two access-to-subprograms, but they are really meant to be completely
>> different sources (one creates tokens from input while the other outputs
>> the token, and the whole point of the separation is to have different
>> input-analysis and output-generation that can plugged together). So in
>> that case, I count them as two independant single-operation cases.
> Your Markdown processor ?

More or less yes. It's actually a generic (lightweight) markup
processor, and Markdown is only one of the input-to-token callback sets.
I'm not sure exactly what kind of expressive power is has, but it's at
least suitable for Creole and Textile too.

The rough design is based around an array created by the client for the
library engine, whose elements are a record containing a lexer callback
(the input-to-token part), a renderer callback (token-to-output), an
indication for engine to not keep calling every entry all the time, and
a priority that breaks ties.

The engine calls the input-to-token part when adequate, which updates
the current position and returns a Token'Class object, which is then fed
to the corresponding token-to-output callback.

One thing I don't like much in this design is that the token type must
match: for example when parsing a link, the input-to-token will create a
Link_Token that contains the linked URI, a title and the link text. The
token-to-output will need all that information, so I'm casting the
Token'Class back into a Link_Token. But what if the client mismatched
the callbacks and it got a String_Token instead? That raises a run-time
exception, while the information is already there at compile-time.

Well in theory an input-to-token callback could create different token
types (e.g. when the link title is optional, instead of putting an
empty string in a Link_Token, have a Titled_Link_Token and a
titleless Link_Token). But I would gladly force each input-to-token
callback to create a single token type if that can be statically checked
against the expected token-to-output type.

Anyway, back to the original point, the library will also provide as
examples standard Markdown, various Markdown extensions, Creole and
Textile input-to-token callback sets, and some output-to-token callback
sets as well (I can't think of anything other than HTML and XHTML right
now). The whole token layer is meant to make them independent, so it
would be counterproductive to make one class for each combination only
to remove two accesses-to-subprogram.

>> My wild guess is that tagged types would need two dereferences while
>> access to subprogram only one,
> With an access to a subprogram, there is a reference to an address and an  
> address dereference; with a tagged type, there is a reference to an  
> instance and a selector (is that the good word? I'm not sure). I see two  
> for both.

Maybe I'm too tainted with C++ implementation details, but what I
imagined was the access-to-subprogram containing the address of the
address of the subprogram, so that's one dereference, while a tagged
type instance would contain a reference to a dispatch table (shared by
all instances) which itself contains a reference to the actual code.

It feels like a waste of resources to have a one-entry dispatch table,
but I'm not sure dealing with it optimally is really worth the extra
complexity in compilers.


Natasha