Re: Streams Quandry in Ada95

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Stephen Leake wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>
> > SHORT PROBLEM DESCRIPTION:
> >
> > The "Ada95" problem surrounds limited types,
> > stream types and abstraction of types/primitives.
> > <snip>
>
> You don't say exactly what the issue is; the code compiles (almost)
> cleanly, and appears to implement your objective. What do you want to
> change? What doesn't work?

The problems are many.  In its present form (after uncommenting the
with clause for codec, and the pump call), gives you:

gnatmake -gnatf main
gnatgcc -c -gnatf main.adb
codec.ads:9:37: subtype mark required in this context
gnatmake: "main.adb" compilation error

If you look at codec.ads you'll see that it expects Audio_Stream.
You cannot convert the streams to Audio_Stream, as attempted
below:

Pump(Audio_Stream(Au_Str),Audio_Stream(DSP_Str));

This gives you:

gnatgcc -c -gnatf main.adb
main.adb:22:10: incorrect use of "Audio_Stream"
main.adb:22:31: incorrect use of "Audio_Stream"
codec.ads:9:37: subtype mark required in this context
gnatmake: "main.adb" compilation error

IGNORING that for a moment however, the REAL issue
is this:

The problem is that the codec routine Pump() cannot
work with its arguments, because they are from an abstract
stream (Audio_Stream).  However, I cannot make them concrete,
unless I choose BEFOREHAND, what streams I want to use (in
this case I would be forced to choose Au_Stream and/or DSP_Stream,
which are derived from Audio_Stream).

But I want to accept _ANY_ Audio_Stream _DERIVED_ stream.

So the question is, do I really have to define a derived stream
with no-op primitives to avoid the "abstract" taint?

i.e.

Au_stream <= no-op <= Audio_Stream(*) <= ... <= Root_Stream_Type(*)
DSP_Stream <= no-op <= Audio_Stream(*) <= ... <= Root_Stream_Type(*)

where (*) is abstract.

I would think that the whole point of abstraction is to force derived objects
to provide those primitives. However, I cannot USE the abstract object itself
(which makes sense-- what I really want to say is I want arguments that
represent any stream derived from the abstract Audio_Stream type).

I can avoid the abstract problem by deriving from Audio_Stream and providing
no-op primitives for the abstract primitives.  But if other streams derive from this,
they may forget to override those no-op primitives (though I could cheat and
raise exceptions... leading to run-time checks).

So how do I write a procedure that says:

procedure Pump(In_Str, Out_Str:  Any_Stream_Derived_From Audio_Stream);

without losing the benefits of what abstract primitives force upon the derived
stream?  I've exhausted all reasonable approaches I can think of here, apart
from the No-op derived stream.

--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg