Re: Starter project: getopt_long in Ada

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Mon, 28 Nov 2011 09:21:51 +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.
Oops, I was unclear, indeed.

Rewording: a specification is probably not just intended to you, and even  
yourself, may behave like someone else some future day. If You (the “I”  
you used) don't see a need for something right now, and drop an  
abstraction for this sole purpose, this may not be a good thing for your  
interface. One may think reusable and abstract when setting up an  
interface, not just think about the actual needs of the moment. Questions  
like “and what if ?” may be good track. As tagged type can to more while  
still being capable of the less, compared to access to subprogram, and  
nothing prevent the use of tagged types, then the idea of tagged types  
should not be dropped with the argument “I don't need at the moment”.  
Otherwise, you will have to change the interface later, and its always  
better to update an implementation than an interface.

Sorry for the smalltalk… I guess you already know all of that (red-face).

> [important snip dropped to be short]
>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.
>
> [important snip dropped to be short]

I won't comment, as I am not sure I have clear mind about it.

> 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.
Both are implementation assumptions. An access type may not be  
dereferenced straight away, at least with Ada which know access type level  
check, and an access type may as much be an index in some array, among  
other things. Many time, you have to use “.all” with access types, and  
when not there, it's there, implicitly: this “.all” does not seems  
warranted to me, to not involve any operation. On the other side, the same  
with tagged types. If a compiler know a XXX_Type'Class only has instance  
of a single known type, then it can avoid all dispatching tables, which  
are anywhere a particular implementation (as an example, SmallEiffel used  
conditional in some case, instead of a VMT, and could even do direct call  
in some other more rare cases). There is no way to assume an access to  
procedure is more or less efficient than what is semantically a  
dispatching call.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: [Epigrams on Programming — Alan J. — P. Yale University]