Re: Streams Quandry in Ada95

Re: Streams Quandry in Ada95

[Stephen Leake]

"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?

-- 
-- Stephe

Re: Streams Quandry in Ada95

[Warren W. Gay VE3WWG]

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

Re: Streams Quandry in Ada95

[tmoran]

>So how do I write a procedure that says:
>
>procedure Pump(In_Str, Out_Str:  Any_Stream_Derived_From Audio_Stream);

 procedure Pump(In_Str, Out_Str: in out Audio_Stream'Class);

>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).
  Forget the no-ops, just make the primitives of the abstract Audio_Stream
themselves abstract.  Then anybody deriving a new non-abstract kind of
Audio_Stream will be *required by the compiler* to supply overrides for
the abstract primitives.
  Thus
type Raw_Sample_Type is range 0 .. 127;  -- or whatever
type Audio_Stream is abstract tagged null record;
function Get(Data : Audio_Stream) return Raw_Sample_Type is abstract;
procedure Put(Sample : in Raw_Sample_Type; Data : in out Audio_Stream)
  is abstract;
procedure Pump(In_Str, Out_Str: in out Audio_Stream'Class);
 ...
procedure Pump(In_Str, Out_Str: in out Audio_Stream'Class) is
  Sample : Raw_Sample_Type;
begin
  loop
    Sample := Get(In_Str);
    Put(Sample, Out_Str);
  end loop;
end Pump;

Is this the sort of thing you want to do?

Re: Streams Quandry in Ada95

[Warren W. Gay VE3WWG]

tmoran@acm.org wrote:

> >So how do I write a procedure that says:
> >
> >procedure Pump(In_Str, Out_Str:  Any_Stream_Derived_From Audio_Stream);
>
>  procedure Pump(In_Str, Out_Str: in out Audio_Stream'Class);
>
> >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).
>   Forget the no-ops, just make the primitives of the abstract Audio_Stream
> themselves abstract.  Then anybody deriving a new non-abstract kind of
> Audio_Stream will be *required by the compiler* to supply overrides for
> the abstract primitives.

Basically, I was already doing that, and agree that it should be done that way.

I just got an email from  Sergey Koshcheyev <serko84@hotmail.com> who I think
has solved this riddle (to be confirmed tonight).  He says: "it looks that the problem
is you're using Audio_Stream as both the package name and the type name, so the
compiler is getting confused..."  I think he may be right.

He continues "...after renaming the package to Audio_Stream_Package (Audio_Streams
may be a better name) and uncommenting the Pump call and the corresponding 'with'es
in main.adb, the code compiles fine,...".

So my problems were probably due to the compiler getting confused in different
contexts about what I was trying to do.

I'll try to confirm this tonight myself, and report back to the group.

Thanks!


> procedure Pump(In_Str, Out_Str: in out Audio_Stream'Class) is
>   Sample : Raw_Sample_Type;
> begin
>   loop
>     Sample := Get(In_Str);
>     Put(Sample, Out_Str);
>   end loop;
> end Pump;
>
> Is this the sort of thing you want to do?

I'll have to check, but type Audio_Stream was already a class-wide type, but
yes, that is the idea. However, as previously mentioned, I believe my woes are
due to naming conflicts that Sergey Koshcheyev wrote to me about.

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

Re: Streams Quandry in Ada95 (SOLVED)

[Warren W. Gay VE3WWG]

"Warren W. Gay VE3WWG" wrote:

> I just got an email from  Sergey Koshcheyev <serko84@hotmail.com> who I think
> has solved this riddle (to be confirmed tonight).  He says: "it looks that the problem
> is you're using Audio_Stream as both the package name and the type name, so the
> compiler is getting confused..."  I think he may be right.

He was right. When I renamed the package to Audio_Streams (plural), this removed
the confusion with the type:

type Audio_Stream is access all Audio_Stream_Type'Class;

With the original name conflict in place, the things I thought were legal to do, were not.
Being relatively new to Ada, I assumed that I was doing something that I shouldn't
be able to do. Once I renamed the package, as per Sergey's advice, I was then able
to do the things I thought you could do.  I defined :

    procedure Pump(In_Str, Out_Str: Audio_Stream)

as required.  To access derived primitives on Au_Stream, all I now need
to do is:

    Chans := Channels(In_Str.All);  -- Determine the # of input audio channels

To set the # of channels on the Out_Str, (for DSP_Stream) then:

    Set_Channels(Out_Str.All,Chans);  -- Configure DSP to use n channel output

The Read/Write on the stream now works as expected:

    Audio_I32'Read(In_Str,I);    -- Read 32 bit int

Life is good!  Thanks everybody.  Sergey wins the prize ;-)

This is the 2nd time I was burnt by the package name.  This time, I'll remember
the lesson.

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

Re: Streams Quandry in Ada95

[Robert Dewar]

In article <3A37D5BC.982E3BDF@home.com>,
  "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote:
> So my problems were probably due to the compiler
> getting confused in different
> contexts about what I was trying to do.

I don't see that your compiler was doing anything
wrong here at all or getting "confused". Perhaps
you might have been confused by the results of
injudicious choice of conflicting names, but I
don't see any basis for claiming that the compiler
was confused here.


Sent via Deja.com
http://www.deja.com/

Re: Streams Quandry in Ada95

[Warren W. Gay VE3WWG]

Robert Dewar wrote:

> In article <3A37D5BC.982E3BDF@home.com>,
>   "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote:
> > So my problems were probably due to the compiler
> > getting confused in different
> > contexts about what I was trying to do.
>
> I don't see that your compiler was doing anything
> wrong here at all or getting "confused". Perhaps
> you might have been confused by the results of
> injudicious choice of conflicting names, but I
> don't see any basis for claiming that the compiler
> was confused here.

The compiler _may_ have been playing by all the rules.. I'm not
making a judgement call on that. As you said however, it did
lead me down the road to the wrong conclusions however. But
now I am now a little wiser ;-)

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

Re: Streams Quandry in Ada95

[Sergey Koshcheyev]

Hi,

I was the first person to choose the word "confused", so probably I shall
reply to this too. Basically, I meant "intentionally confused", since Ada
compilers are required not to be too smart by the Ada standard. A C/C++
compiler in a similar situation (package name/type name conflict) would
probably understand that the programmer meant the type, since a package name
isn't allowed in that context.

Obligatory note: I'm not saying that C/C++ is better, only that the
compilers have to be smarter :-)

Of course, GNAT wasn't really confused in this situation, in fact the error
message contained a reference to the declaration of the conflicting package.

Sergey

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:91ad7r$ic6$1@nnrp1.deja.com...
> In article <3A37D5BC.982E3BDF@home.com>,
>   "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote:
> > So my problems were probably due to the compiler
> > getting confused in different
> > contexts about what I was trying to do.
>
> I don't see that your compiler was doing anything
> wrong here at all or getting "confused". Perhaps
> you might have been confused by the results of
> injudicious choice of conflicting names, but I
> don't see any basis for claiming that the compiler
> was confused here.
>
>
> Sent via Deja.com
> http://www.deja.com/

Re: Streams Quandry in Ada95

[Anders Gidenstam]

In article <3A37B3C3.86CFCF66@home.com>,
	"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>
>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.
>

Hello!

Atleast one thing is for sure, and that is that Pump won't
accept any argument of type Au_Stream_Type, since that type
isn't derived from Audio_Stream_Type..
Anyway, I'm not sure I understand what the other problem is,
couldn't you define the operations you need to manipulate any
stream derived from Audio_Stream_Type as abstract subprograms
along with the definition of Audio_Stream_Type?

Just my 0.25 sek..

Regards

Anders Gidenstam
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming