Intermixing two tagged types

Intermixing two tagged types

[Victor Porton]

I am implementing thick Ada2012 bindings for 
http://librdf.org/raptor/api/raptor2-section-xml-namespace.html

This documentation defines two types:
raptor_namespace and raptor_namespace_stack.

Methods for these types are essentially C functions whose name start with
raptor_namespace_
raptor_namespaces_
correspondingly.

Now to the trouble (or rather a problem):

Some of these functions accept only one the two types: raptor_namespace or 
raptor_namespace_stack.

But there are functions (let's call them "suspicious functions") which 
accept both raptor_namespace or raptor_namespace_stack types as its 
arguments.

To make things worse, some of suspicious functions have raptor_namespace_ 
and some raptor_namespaces_ prefix.

So (now in Ada terms, which I am implementing) a function can belong to two 
tagged types.

How to formalize this in Ada?

I see two variants:

1. Put them into two different packages and do "limited with" from each of 
the two packages to the other one.

2. Make all suspicious functions belonging to one certain Ada package (which 
of the two?)

I could both types into the same package, but this causes troubles described 
in <Trouble with "operation can be dispatching in only one type"> 
comp.lang.ada topic.

Please give a good advise what to do in this situation.

-- 
Victor Porton - http://portonvictor.org

Re: Intermixing two tagged types

[Simon Wright]

Victor Porton <porton@narod.ru> writes:

> So (now in Ada terms, which I am implementing) a function can belong
> to two tagged types.

Are you sure that it's appropriate to use *tagged* types? And even if if
is appropriate for raptor_namespace (i.e., you derive new types from
it), is it so for raptor_namespace_stack? - which clearly is a stack of
raptor_namespace (or possibly raptor_namespace'Class).

Re: Intermixing two tagged types

[Victor Porton]

Simon Wright wrote:

> Victor Porton <porton@narod.ru> writes:
> 
>> So (now in Ada terms, which I am implementing) a function can belong
>> to two tagged types.
> 
> Are you sure that it's appropriate to use *tagged* types? And even if if
> is appropriate for raptor_namespace (i.e., you derive new types from
> it), is it so for raptor_namespace_stack? - which clearly is a stack of
> raptor_namespace (or possibly raptor_namespace'Class).

Tagged types a little decrease efficiency, but I use tagged types anyway 
(primarily for controlled finalization).

-- 
Victor Porton - http://portonvictor.org

Re: Intermixing two tagged types

[Dmitry A. Kazakov]

On Thu, 14 Aug 2014 14:57:18 +0300, Victor Porton wrote:

> Simon Wright wrote:
> 
>> Victor Porton <porton@narod.ru> writes:
>> 
>>> So (now in Ada terms, which I am implementing) a function can belong
>>> to two tagged types.
>> 
>> Are you sure that it's appropriate to use *tagged* types? And even if if
>> is appropriate for raptor_namespace (i.e., you derive new types from
>> it), is it so for raptor_namespace_stack? - which clearly is a stack of
>> raptor_namespace (or possibly raptor_namespace'Class).
> 
> Tagged types a little decrease efficiency,

There is none, except the place used to keep the type tag. Since non-tagged
types do not dispatch, whatever dispatch overhead does not apply.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Intermixing two tagged types

[Adam Beneschan]

On Thursday, August 14, 2014 4:57:18 AM UTC-7, Victor Porton wrote:

> Tagged types a little decrease efficiency, but I use tagged types anyway 
> (primarily for controlled finalization).

I haven't been following this discussion carefully enough.  So I have no idea whether the following suggestion is appropriate.  However ...

If you have an untagged record, and it has a component that is a (tagged) controlled type, you'll still get finalization, but using the untagged record as a parameter won't cause any problems with the dispatching rules.

Again, I don't know whether this is helpful.  I just thought I'd throw it out there in case it is.

                                  -- Adam

Re: Intermixing two tagged types

[Victor Porton]

Adam Beneschan wrote:

> On Thursday, August 14, 2014 4:57:18 AM UTC-7, Victor Porton wrote:
> 
>> Tagged types a little decrease efficiency, but I use tagged types anyway
>> (primarily for controlled finalization).
> 
> I haven't been following this discussion carefully enough.  So I have no
> idea whether the following suggestion is appropriate.  However ...
> 
> If you have an untagged record, and it has a component that is a (tagged)
> controlled type, you'll still get finalization, but using the untagged
> record as a parameter won't cause any problems with the dispatching rules.
> 
> Again, I don't know whether this is helpful.  I just thought I'd throw it
> out there in case it is.

Thank you for your suggestion. However I already know this.

But working this way would be a wrong way. In the meaning of things the 
entire record is controlled, not its part. So controlling a part would be a 
hack, not a good way to do programming.

-- 
Victor Porton - http://portonvictor.org

Re: Intermixing two tagged types

[Adam Beneschan]

On Thursday, August 14, 2014 9:11:02 AM UTC-7, Victor Porton wrote:

> Thank you for your suggestion. However I already know this.
> 
> But working this way would be a wrong way. In the meaning of things the 
> entire record is controlled, not its part. So controlling a part would be a 
> hack, not a good way to do programming.

Unfortunately, sometimes you have make compromises to work around the language.

Anyway, if your untagged type has just *one* component that is the "entire" record, that might be close enough to the "right" way to make you feel you're not using a hack--or at least you're using only a minor hack.  If you give the component a one-letter name like R, then it means you have to add "R." every time you want to access a field in your record.  It's a nuisance.  But it might be the least of evils.

I've had to do things like this; usually it's when I have a variant record with a discriminant with a default, like:

    type Value (Value_Type : Value_Classes := Value_Classes'First) is record
        case Value_Classes is
           ...
        end case;
    end record;

(A lot of this was written in the Ada 83 days.)  The rules allow you to change the discriminant of a Value by reassigning the whole record.  But you *can't* do this if you have an "access Value" Acc; you can't change the discriminant of Acc.all by reassigning it.  You *can*, however, wrap Value in another record (with one component V), and if you have an "access Value_Wrapper" Wrapper_Acc, you can change the discriminant of Wrapper_Acc.V.all.  Annoying, but it works.  There were reasons why this rule is in the language, but I wish it had provided a way to let me allocate a "new Value" whose discriminant can be changed.  Providing too many options, however, can muddy the syntax of the language, so it's a trade-off between adding language rules that require annoying workarounds like this, and providing so many features that it drives everybody crazy (language designers, implementors, users) and increases the chance of mistakes or unsafe features creeping into the language semantics.

Bottom line is: there is no Holy Grail of a perfect language, and if you wait for a language that never requires you to do things a "wrong" way, you will be waiting a very, very long time.  We'll probably solve the halting problem  before we can produce a language like that.  :)

                                -- Adam