On packages hierarchy

On packages hierarchy

[Victor Porton]

I am going to create the package RDF.Raptor.Iostream which would be Ada 
bindings around
http://librdf.org/raptor/api/raptor2-section-iostream.html

Afterward, I am going to create Ada IO stream (derived from 
Root_Stream_Type) which encaspulates (wraps) RDF.Raptor.Iostream and 
reversely RDF.Raptor.Iostream which encaspulates (wraps) Root_Stream_Type.

Should packages which wrap each other be in child packages of 
RDF.Raptor.Iostream? I think no, because they do not require access to 
internals (private part) of RDF.Raptor.Iostream but child packages have 
access to private parts.

So, should they be siblings, like RDF.Raptor.Iostream_To_Ada and 
RDF.Raptor.Iostream_From_Ada? (Also please help to conceive good names for 
these packages.)

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

Re: On packages hierarchy

[Shark8]

On 28-Jul-14 07:41, Victor Porton wrote:
> I am going to create the package RDF.Raptor.Iostream which would be Ada
> bindings around
> http://librdf.org/raptor/api/raptor2-section-iostream.html
>
> Afterward, I am going to create Ada IO stream (derived from
> Root_Stream_Type) which encaspulates (wraps) RDF.Raptor.Iostream and
> reversely RDF.Raptor.Iostream which encaspulates (wraps) Root_Stream_Type.
>
> Should packages which wrap each other be in child packages of
> RDF.Raptor.Iostream? I think no, because they do not require access to
> internals (private part) of RDF.Raptor.Iostream but child packages have
> access to private parts.
>
> So, should they be siblings, like RDF.Raptor.Iostream_To_Ada and
> RDF.Raptor.Iostream_From_Ada? (Also please help to conceive good names for
> these packages.)
>

Er, why?

> Streams are a method to read or write any object to any medium,
> and thus they are doubly generalized. This also means that you
> are bounded by the most restrictive set of operations common to
> all mediums. As an example, you cannot provide position control
> in a general manner because not all transmission modes are
> random-access (like receiving a radio-signal), and not all
>  streams are bi-directional (like a light-sensor).

Why not just have a single stream type?
Moreover, Ada's root-stream is abstract, so you can't have objects of 
that type.

Re: On packages hierarchy

[Victor Porton]

Shark8 wrote:

> On 28-Jul-14 07:41, Victor Porton wrote:
>> I am going to create the package RDF.Raptor.Iostream which would be Ada
>> bindings around
>> http://librdf.org/raptor/api/raptor2-section-iostream.html
>>
>> Afterward, I am going to create Ada IO stream (derived from
>> Root_Stream_Type) which encaspulates (wraps) RDF.Raptor.Iostream and
>> reversely RDF.Raptor.Iostream which encaspulates (wraps)
>> Root_Stream_Type.
>>
>> Should packages which wrap each other be in child packages of
>> RDF.Raptor.Iostream? I think no, because they do not require access to
>> internals (private part) of RDF.Raptor.Iostream but child packages have
>> access to private parts.
>>
>> So, should they be siblings, like RDF.Raptor.Iostream_To_Ada and
>> RDF.Raptor.Iostream_From_Ada? (Also please help to conceive good names
>> for these packages.)
>>
> 
> Er, why?
> 
>> Streams are a method to read or write any object to any medium,
>> and thus they are doubly generalized. This also means that you
>> are bounded by the most restrictive set of operations common to
>> all mediums. As an example, you cannot provide position control
>> in a general manner because not all transmission modes are
>> random-access (like receiving a radio-signal), and not all
>>  streams are bi-directional (like a light-sensor).
> 
> Why not just have a single stream type?

I want to make an interface to streams of Raptor C library.

Because, as you say, we are to have a single stream type, this type should 
be well-interfaces with that "single" Ada stream class.

> Moreover, Ada's root-stream is abstract, so you can't have objects of
> that type.

Well, I mean object of Root_Stream_Type'Class.

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

Re: On packages hierarchy

[Shark8]

On 28-Jul-14 10:35, Victor Porton wrote:
>> Why not just have a single stream type?
> I want to make an interface to streams of Raptor C library.
>
> Because, as you say, we are to have a single stream type, this type should
> be well-interfaces with that "single" Ada stream class.
>
>> >Moreover, Ada's root-stream is abstract, so you can't have objects of
>> >that type.
> Well, I mean object of Root_Stream_Type'Class.

Again, why?
Your Raptor-stream type /will/ be an concrete-instance of 
Root_stream_type, and a member of its class, won't it? I mean unless I'm 
completely misunderstanding you...

     Use Ada.Streams;
     Type Dave is new Root_Stream_Type with null record;


     overriding procedure Read
      (Stream : in out Dave;
       Item   : out Stream_Element_Array;
       Last   : out Stream_Element_Offset);


    procedure Write
      (Stream : in out Dave;
       Item   : Stream_Element_Array);

---- Implementation:

  overriding procedure Read
      (Stream : in out Dave;
       Item   : out Stream_Element_Array;
       Last   : out Stream_Element_Offset)
    is null; -- Replace this with actual implementation.

  overriding procedure Write
      (Stream : in out Dave;
       Item   : Stream_Element_Array)
    is null; -- Replace this with actual implementation.

Perhaps reading the first and second posts on this thread will help you 
understand:

http://computer-programming-forum.com/44-ada/07c6cd94dbb2d6b1.htm

Re: On packages hierarchy

[Victor Porton]

Shark8 wrote:

> On 28-Jul-14 10:35, Victor Porton wrote:
>>> Why not just have a single stream type?
>> I want to make an interface to streams of Raptor C library.
>>
>> Because, as you say, we are to have a single stream type, this type
>> should be well-interfaces with that "single" Ada stream class.
>>
>>> >Moreover, Ada's root-stream is abstract, so you can't have objects of
>>> >that type.
>> Well, I mean object of Root_Stream_Type'Class.
> 
> Again, why?
> Your Raptor-stream type /will/ be an concrete-instance of
> Root_stream_type, and a member of its class, won't it? I mean unless I'm
> completely misunderstanding you...

My raptor stream is derived from some my base class.

Due no multiple type inheritance in Ada, it cannot be also derived from 
Root_Stream_Type. So I need a wrapper type.

>      Use Ada.Streams;
>      Type Dave is new Root_Stream_Type with null record;
> 
> 
>      overriding procedure Read
>       (Stream : in out Dave;
>        Item   : out Stream_Element_Array;
>        Last   : out Stream_Element_Offset);
> 
> 
>     procedure Write
>       (Stream : in out Dave;
>        Item   : Stream_Element_Array);
> 
> ---- Implementation:
> 
>   overriding procedure Read
>       (Stream : in out Dave;
>        Item   : out Stream_Element_Array;
>        Last   : out Stream_Element_Offset)
>     is null; -- Replace this with actual implementation.
> 
>   overriding procedure Write
>       (Stream : in out Dave;
>        Item   : Stream_Element_Array)
>     is null; -- Replace this with actual implementation.
> 
> Perhaps reading the first and second posts on this thread will help you
> understand:
> 
> http://computer-programming-forum.com/44-ada/07c6cd94dbb2d6b1.htm
-- 
Victor Porton - http://portonvictor.org

Re: On packages hierarchy

[Shark8]

On 29-Jul-14 06:36, Victor Porton wrote:
> My raptor stream is derived from some my base class.

Why?
Is there some reason it needs to be exposed to the rest of the binding?
If so, why does it need to be exposed separately from the derivation of 
Root_Stream_Type? This is to say given a derivation from 
Root_Stream_Type, why not have all parameters that need that type use 
that type?

Is it because you want some uniformity of interface?
In that case you could have the "base class" be an interface rather than 
a tagged type -- in fact you could do both: have a base-interface from 
which your normal raptor-types are rooted in an abstract type and have 
the limited types derive from the interface. Ex:

     package test is
         Type Raptor is limited interface;
         -- All common operations of all raptor-types go here.
         Procedure First_Stub(Input: Raptor) is abstract;



         Type Raptor_Base is abstract new Raptor with null record;

         Type Raptor_Stream is new Ada.Streams.Root_Stream_Type and 
Raptor with
           null record;

         Overriding
         Procedure First_Stub(Input: Raptor_Stream) is null;

         Overriding
         procedure Read
           (Stream : in out Raptor_Stream;
            Item   : out Stream_Element_Array;
            Last   : out Stream_Element_Offset)
         is null;

         Overriding
         procedure Write
           (Stream : in out Raptor_Stream;
            Item   : Stream_Element_Array)
         is null;
     end test;



> Due no multiple type inheritance in Ada, it cannot be also derived from
> Root_Stream_Type. So I need a wrapper type.

Why expose the raptor-stream at all?
A lot of your problems seem to stem from trying to build from the 
low-level thin-binding to the high-level thick-binding while trying to 
keep [and expose] the low-level/thin-binding; try going the other way:
*Design the high-level binding first, /then/ in the hidden 
implementation/bodies implement-and-use the low-level binding.*

As a trivial example, consider OpenGL's gl_enum type and all the 
functions that use it with restrictions best used/expressed as 
full-blown types:

     package GL_Example is
         GL_MAX_LIGHTS : constant := 8;

         -- Light is a biased-representation of 1..8.
         -- May be implementation dependant, can be rectified with
         -- an expression function in the implementation call.
         Type Light_Number is range 1..GL_MAX_LIGHTS with size => 3;

         -- Safe_Float disallows non-numeric values.
         SubType Safe_Float is Float range Float'First..Float'Last;

         -- Enumeration of Open_GL's parameters for glLightf
         Type Light_Parameters is
           (SPOT_EXPONENT, SPOT_CUTOFF, CONSTANT_ATTENUATION, 
LINEAR_ATTENUATION, QUADRATIC_ATTENUATION);

         -- Thick Binding function.
         Procedure Light( Light_No  : Light_Number;
                          Parameter : Light_Parameters;
                          Value     : Safe_Float
                        ) with Inline;
     end GL_Example;

     package body GL_Example is
         -- GL Types
         Type GL_Enum  is new Interfaces.Unsigned_32;
         Type GL_Float is new Interfaces.IEEE_Float_32
			 Range Interfaces.IEEE_Float_32'Range;

         -- Conversions
         Function Convert is new Unchecked_Conversion
           (Source => Light_Number, Target => GL_Enum);
         Function Convert is new Unchecked_Conversion
           (Source => Light_Parameters, Target => GL_Enum);
         Function Convert is new Unchecked_Conversion
           (Source => Safe_Float, Target => GL_Float);



         -- Imported (thin-binding) functions
         procedure glLightf (light, pname : GL_Enum; param : GL_Float)
	with Import, Convention => stdcall, External_Name => "glLightf";

         -- Thick-binding bodies
         Procedure Light (Light_No  : Light_Number;
                          Parameter : Light_Parameters;
                          Value     : Safe_Float
                         ) is
         begin
             glLightf( Convert(Light_No), Convert(Parameter), 
Convert(Value) );
         end Light;

     end GL_Example;

Re: On packages hierarchy

[Simon Wright]

Shark8 <OneWingedShark@gmail.com> writes:

>         Function Convert is new Unchecked_Conversion
>           (Source => Light_Number, Target => GL_Enum);

Given that Light_Number'Size is set to 3 (above), and is biased into the
bargain, I don't see how this is going to work reliably? GNAT is
certainly going to give you warnings about source & target having
different sizes.

I've often used a constant array (source) of target to do conversions
like this.

Re: On packages hierarchy

[Shark8]

On 29-Jul-14 13:42, Simon Wright wrote:
> Given that Light_Number'Size is set to 3 (above), and is biased into the
> bargain, I don't see how this is going to work reliably? GNAT is
> certainly going to give you warnings about source & target having
> different sizes.

It should work as expected:

> testbed.adb:37:58: warning: size clause forces biased representation for "Light_Number"
> testbed.adb:60:09: warning: types for unchecked conversion have different sizes
> testbed.adb:60:09: warning: size of "Light_Number" is 3, size of "Gl_Enum" is 32
> testbed.adb:60:09: warning: source will be extended with 29 high order zero bits
>...

and ( from 
http://docs.adacore.com/gnat-unw-docs/html/gnat_rm_9.html#SEC485 )
>  For example, suppose we have the declaration:
>
>  	
>
>    type Small is range -7 .. -4;
>    for Small'Size use 2;
>
> Although the default size of type Small is 4, the Size clause is accepted by GNAT and
> results in the following representation scheme:
>
>  	
>
>   -7 is represented as 2#00#
>   -6 is represented as 2#01#
>   -5 is represented as 2#10#
>   -4 is represented as 2#11#

Which means that:
1 would be represented ad 2#000#
2 would be represented ad 2#001#
3 would be represented ad 2#010#
etc
That internal representation *is* the zero-based indexing that OpenGL 
expects, and Convert (as shown above) extends its size with zero-bits.

So there's no reason it shouldn't work.
Granted it's going off a lot of implementation-defined behavior and your 
method of an array or my suggestion of a proper conversion-function 
expression-function would handle this in an implementation independent 
manner.