Re: List container strawman 1.2

[t_wolf@angelfire.com (Thomas Wolf)]

Marin David Condic wrote:

> I knew that their *behavior* is defined in terms of 'Read and 'Write, but I
> did not know that you would get them to come along free for the cost of
> defining your own overrides for 'Read and 'Write. I was under the impression
> that you'd still have to make your own procedures and do a for-use. If this
> is not the case, then great - nice to get something as a freebie.
> 
> "Thomas Wolf" <t_wolf@angelfire.com> wrote in message
> news:3C049C06.DF85EF80@angelfire.com...
> >
> > Why? 'Output and 'Input are defined in terms of 'Write and 'Read (see
> > RM 13.13.2), so it generally suffices to define the latter.
> >

The RM defines *more* than just the behavior of, say, 'Output: it defines
the implementation!

The RM says (quoting from RM 13.13.2 (27))

(RM 13.13.2 (25): "Unless overridden by an attribute_definition_clause...")

"S'Output then calls S'Write to write the value of Item to the stream. ..."

It *doesn't* say "S'Output behaves as if it called S'Write..." or some
such!

In fact, all of 'Output, 'Input, 'Class'Output, 'Class'Input,
'Class'Write and 'Class'Read by definition in the RM ultimately call
'Write or 'Read. Hence, if you implement 'Write and 'Read, you *do* get
the others for free.

(Just as you do get "/=" for free if you define "=". I haven't quite
understood why something similar hasn't been defined for the relational
operators: once you've defined "<", the other three (">", "<=", and ">=")
follow automatically: L <= R is (not (R < L)); L >= R is (not (L < R)),
and of course L > R is R < L. Does it maybe have something to do with
floating point?)

The only minor nit I have with the definitions in the RM is that the
class-wide 'Input and 'Output operations are defined to write the tag
by calling String'Output(Ada.Tags.External_Tag (Item'Tag)), and one
thus ends up with both the lower and the upper bound of the string in
the stream, followed by the string content. This wastes space: in my
eyes, it'd suffice to write the *length* of the tag string.

Unfortunately, this cannot be "corrected" by redefining 'Class'Output
and 'Class'Input, because the latter needs, once it has read the tag
and converted it to an internal tag, to dispatch to the 'Input
operation of the type identified by this very internal tag -- and
Ada 95 doesn't provide any way to do this, it just happens
"automagically" in some compiler-specific fashion inside the
default 'Input.

And while I'm on it (I've noticed that this post somehow has turned 
into a list of minor missing features in Ada 95 :-), I also miss an
"is_a" operator. (I am aware of "in", but unless I'm missing something,
it doesn't solve the following problem.)

Consider

   type Something is tagged null record;

   procedure Do_Something (A, B : in out Something'Class);
     -- Whatever 'Do_Something' does, it shall only do it if the type
     -- of B is directly or indirectly derived from the type of A.

I have not found any easy way to do this (not even using Ada.Tags),
except requiring that any type in Something'Class have a primitive
operation

   function Is_A (Test : in Something'Class; Target : in Something)
     return Boolean;

and invoke that from inside 'Do_Something'.

So, if there is

   type Foo is new Something with null record;

   function Is_A (Test : in Something'Class; Target : in Foo)
     return Boolean
   is
   begin
     return Test in Foo'Class;
   end Is_A;

and 

   procedure Do_Something (A, B : in out Something'Class)
   is
   begin
      if Is_A (B, A) then
        ...

then it works. But it would be really nice if one could avoid all
this overhead. My proposal would be to allow 'Class to be applied
to *objects* of tagged or class-wide types. (It currently can be
applied to tagged *types* only.) In that case, I could have just
written

   procedure Do_Something (A, B : in out Something'Class)
   is
   begin
      if B in A'Class then
        ...

Alas, the current RM doesn't allow this...
   
--
---------------------------------------------------------------------
Dr. Thomas Wolf                          e-mail: t_wolf@angelfire.com