Re: Private discrete type as index

Re: Private discrete type as index

[James S. Rogers]

"AG" <ang@xtra.co.nz> wrote in message
news:RKJT9.21144$F63.395685@news.xtra.co.nz...
> Hi all,
>
> Guess I have a question that I'm a bit puzzled about.
> Consider the boiled-down code snippet:
>
> package test is
>   type x is limited private;
>   type test is array(x) of boolean;
> private
>     type x is new boolean;
> end test;
>
> Trying to compile that fails on GNAT
> with "Discrete type required" error.
> Can't blame it, of course, since it's
> correct according to LRM. But...
>
> the obvious intention was to provide
> a set of "+/-" operations etc on the
> limited type (which are not trivial)
> and prevent the out-of-package clients
> from messing with the index.
>
> Since the compiler obviously knows
> the implementation details, why not?
>
> Of course, it can be implemented as
> an iterator, but what's wrong with
> the example as written? After all,
> the client modules can't use that
> index other than through the type
> and operation provided by the
> package. Compiler/linker sure knows
> what the type is. So, why not?

At the point of declaration of the array type the index type
is not specified as a discrete type. The array type is not private.
The nature of the index type must be visible within the scope of
the declaration of the array type.

You can try an approach like the following, which does compile:

package Type_Definition is
   type Index_Type is limited private;
private
   type Index_Type is new Integer range 1..10;
end Type_Definition;

package Type_Definition.Collection is
   type Collection is limited private;
private
   type Collection is array(Index_Type) of Boolean;
end Type_Definition.Collection;

Of course, each package would also have primitive subprograms
to manipulate the values.

Note in the example above, the array is defined in the private
part of the child package, which has visibility to the private part
of the parent package.

Jim Rogers

Re: Private discrete type as index

[James S. Rogers]

"AG" <ang@xtra.co.nz> wrote in message
news:hULT9.21355$F63.398611@news.xtra.co.nz...
>
> "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> news:8pLT9.105190$hK4.8530896@bgtnsc05-news.ops.worldnet.att.net...
>
> > At the point of declaration of the array type the index type
> > is not specified as a discrete type. The array type is not private.
> > The nature of the index type must be visible within the scope of
> > the declaration of the array type.
>
> True, and the example you give below is fine *if* you want
> to hide from the user the fact that the construct is an array
> (that's what I meant by "iterator").
>
> However, what if you want to let your clients know that
> that the structure is indeed an array and provide appropriate
> operations on the index but prevent them from directly
> manipulating it?

I am unclear what you mean by "providing appropriate operations"
without allowing direct manipulation. This sounds like an iterator to
me. Please describe what you have in mind instead.

Jim Rogers

Re: Private discrete type as index

[Dmitry A. Kazakov]

AG wrote:

> package test is
> 
> type X is new Integer; -- What I'd like here is "limited private" instead
> of "new integer"
> 
> type Test is array(X) of Boolean;
> 
> function "+"(Left: X) return X; -- Unary increment (however that may be
> implemented)
> 
> function "+"(Left:X; N: Integer) return X; -- Shift by N positions (does
> not equal N times other "+")
> 
> private
> 
> -- Defiinition of "X" here whatever it may be
> 
> end test;
> 
> The code above compiles fine. Replacing "new Integer" with "limited
> private" does not.
> 
> But, if it did, it would allow the user of the package to do things like
> 10th position from
> 
> wherever the index is now and it would be the responsibility of the
> implementation
> 
> to know what/where it is. At the same time, the client package would have
> no clue
> 
> as to what the type is or be able to operate on it directly (only through
> any functions
> 
> provided by the package which was the whole point).

Ada does not have user index types other than publicly derived from discrete 
types. "limited private" is not such a type. You could make a sort of 
private type out of a discrete type by disallowing some of its predefined 
operations (making them abstract), but you are unable to make it limited, 
because ":=" is not overridable. Neither can you expose a private type as 
an array. Alas, ADT is far incomplete in Ada.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Private discrete type as index

[Charles H. Sampson]

AG <ang@xtra.co.nz> wrote:

> "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> news:TwPT9.105450$hK4.8563792@bgtnsc05-news.ops.worldnet.att.net...
> 
> > "AG" <ang@xtra.co.nz> wrote in message
> > > However, what if you want to let your clients know that
> > > that the structure is indeed an array and provide appropriate
> > > operations on the index but prevent them from directly
> > > manipulating it?
> 
> >
> > I am unclear what you mean by "providing appropriate operations"
> > without allowing direct manipulation. This sounds like an iterator to
> > me. Please describe what you have in mind instead.
> >
> 
> OK, here it is:
> 
> package test is
> 
> type X is new Integer; -- What I'd like here is "limited private" instead of
> "new integer"
> 
> type Test is array(X) of Boolean;
> 
> function "+"(Left: X) return X; -- Unary increment (however that may be
> implemented)
> 
> function "+"(Left:X; N: Integer) return X; -- Shift by N positions (does not
> equal N times other "+")
> 
> private
> 
> -- Defiinition of "X" here whatever it may be
> 
> end test;

     It looks like you have an ADT that you've chosen to implement as 
an array.  If that's true, the fact that you've chosen an array, 
rather than a linked list or something else, is an implementation 
decision and should be hidden in the package or its private part.

     I'm guessing that you want the user to know that you've used an 
array for the ease of access to its components.  Unfortunately, losing 
that ease of access is one of the prices you pay for the benefit of 
the abstraction (information hiding).  I don't think it would be 
onerous to the ADT's users to have to employ a "retrieve component" 
function and a "store component" procedure. 

> The code above compiles fine. Replacing "new Integer" with "limited private"
> does not.
> 
> But, if it did, it would allow the user of the package to do things like
> 10th position from
> 
> wherever the index is now and it would be the responsibility of the
> implementation
> 
> to know what/where it is. At the same time, the client package would have no
> clue
> 
> as to what the type is or be able to operate on it directly (only through
> any functions
> 
> provided by the package which was the whole point).

                                Charlie

-- 
     For an email response, my real user name is csampson and my ISP is
inetworld.net.

Private discrete type as index

[AG]

Hi all,

Guess I have a question that I'm a bit puzzled about.
Consider the boiled-down code snippet:

package test is
  type x is limited private;
  type test is array(x) of boolean;
private
    type x is new boolean;
end test;

Trying to compile that fails on GNAT
with "Discrete type required" error.
Can't blame it, of course, since it's
correct according to LRM. But...

the obvious intention was to provide
a set of "+/-" operations etc on the
limited type (which are not trivial)
and prevent the out-of-package clients
from messing with the index.

Since the compiler obviously knows
the implementation details, why not?

Of course, it can be implemented as
an iterator, but what's wrong with
the example as written? After all,
the client modules can't use that
index other than through the type
and operation provided by the
package. Compiler/linker sure knows
what the type is. So, why not?

Re: Private discrete type as index

[AG]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:8pLT9.105190$hK4.8530896@bgtnsc05-news.ops.worldnet.att.net...

> At the point of declaration of the array type the index type
> is not specified as a discrete type. The array type is not private.
> The nature of the index type must be visible within the scope of
> the declaration of the array type.

True, and the example you give below is fine *if* you want
to hide from the user the fact that the construct is an array
(that's what I meant by "iterator").

However, what if you want to let your clients know that
that the structure is indeed an array and provide appropriate
operations on the index but prevent them from directly
manipulating it?

>
> You can try an approach like the following, which does compile:
>
> package Type_Definition is
>    type Index_Type is limited private;
> private
>    type Index_Type is new Integer range 1..10;
> end Type_Definition;
>
> package Type_Definition.Collection is
>    type Collection is limited private;
> private
>    type Collection is array(Index_Type) of Boolean;
> end Type_Definition.Collection;

Re: Private discrete type as index

[AG]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:TwPT9.105450$hK4.8563792@bgtnsc05-news.ops.worldnet.att.net...

> "AG" <ang@xtra.co.nz> wrote in message
> > However, what if you want to let your clients know that
> > that the structure is indeed an array and provide appropriate
> > operations on the index but prevent them from directly
> > manipulating it?

>
> I am unclear what you mean by "providing appropriate operations"
> without allowing direct manipulation. This sounds like an iterator to
> me. Please describe what you have in mind instead.
>

OK, here it is:

package test is

type X is new Integer; -- What I'd like here is "limited private" instead of
"new integer"

type Test is array(X) of Boolean;

function "+"(Left: X) return X; -- Unary increment (however that may be
implemented)

function "+"(Left:X; N: Integer) return X; -- Shift by N positions (does not
equal N times other "+")

private

-- Defiinition of "X" here whatever it may be

end test;



The code above compiles fine. Replacing "new Integer" with "limited private"
does not.

But, if it did, it would allow the user of the package to do things like
10th position from

wherever the index is now and it would be the responsibility of the
implementation

to know what/where it is. At the same time, the client package would have no
clue

as to what the type is or be able to operate on it directly (only through
any functions

provided by the package which was the whole point).

Re: Private discrete type as index

[Keith Thompson]

"AG" <ang@xtra.co.nz> writes:
> Guess I have a question that I'm a bit puzzled about.
> Consider the boiled-down code snippet:
> 
> package test is
>   type x is limited private;
>   type test is array(x) of boolean;
> private
>     type x is new boolean;
> end test;
> 
> Trying to compile that fails on GNAT with "Discrete type required"
> error.  Can't blame it, of course, since it's correct according to
> LRM. But...
> 
> the obvious intention was to provide a set of "+/-" operations etc
> on the limited type (which are not trivial) and prevent the
> out-of-package clients from messing with the index.
> 
> Since the compiler obviously knows the implementation details, why
> not?
> 
> Of course, it can be implemented as an iterator, but what's wrong
> with the example as written? After all, the client modules can't use
> that index other than through the type and operation provided by the
> package. Compiler/linker sure knows what the type is. So, why not?

I think you really want to overload the array indexing operation.  Ada
doesn't let you do that.

If you want your index type to be limited private, you'll have to
provide the indexing operations (setting and retrieving elements) as
explicit functions.  If you want to use actual array indexing, you'll
need to use a visibly discrete index type.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: Private discrete type as index

[tmoran]

>   type x is limited private;
>   type test is array(x) of boolean;
  The "array" abstraction has certain characteristics, among them
sequential indexing.  The object being implemented here is not an array.
If read-only, perhaps it's a function.  For read/write, perhaps a
function returning a pointer would be the syntactically simplest
approach.
  test_object(x).all := not test_object(y).all;
To allow multiple objects, of course, will require an additional
parameter, hidden or not, to distinguish which one.

Re: Private discrete type as index

[Dmitry A. Kazakov]

tmoran@acm.org wrote:

>>   type x is limited private;
>>   type test is array(x) of boolean;
>   The "array" abstraction has certain characteristics, among them
> sequential indexing.

Why so? Array is just a mapping index->element, so if no index ranges 
required then the array index need not to be ordered (have "<" and "="), 
only "=" is required. Anyway a limited type is allowed to have both.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Private discrete type as index

[tmoran]

>> >>   type x is limited private;
>> >>   type test is array(x) of boolean;
>> >   The "array" abstraction has certain characteristics, among them
>> > sequential indexing.
>> Why so? Array is just a mapping index->element, so if no index ranges
>I suppose the answer will be that index ranges *are* required
>by the array semantics (in Ada, at least). But, as you pointed out:
  Perhaps to some people an array is a general map, but to me, and
to at least the on-line glossaries I checked, it's not that general.
Your abstraction appears to be a general mapping from elements of
some set to booleans.  Type "x" might be character strings and
Test(x) True iff a symbol table has seen that string before.  That's
a perfectly good map, but, IMHO, not something well modeled as an array.
  My point is that your abstract object doesn't match the idea of
"array" sufficiently well, and thus probably shouldn't be implemented
with an array.

Re: Private discrete type as index

[Dmitry A. Kazakov]

AG wrote:

> 
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:b0435c$la5bg$1@ID-77047.news.dfncis.de...
>> tmoran@acm.org wrote:
>>
>> >>   type x is limited private;
>> >>   type test is array(x) of boolean;
>> >   The "array" abstraction has certain characteristics, among them
>> > sequential indexing.
>>
>> Why so? Array is just a mapping index->element, so if no index ranges
>> required then the array index need not to be ordered (have "<" and "="),
>> only "=" is required.
> 
> I suppose the answer will be that index ranges *are* required
> by the array semantics (in Ada, at least).

But we are no more talking about Ada. (:-)) In Ada it is anyway impossible. 

And as for array semantics I would like to have two different kinds of 
arrays: ones with an ordered index (like in Ada) and others with an 
unordered index. Unordered arrays could to be used when index order may 
vary from platform to platform (so programmer cannot rely on ranges) and 
maybe for sparse arrays with very large indices and list representation.

> But, as you pointed out:
> 
>> Anyway a limited type is allowed to have both.
> 
> So, it should be able to meet the range requirements too.
> At least if the provider of the type also provides the minimum
> set of operations.

Such as ranges and the operations "..", 'range etc. This is even more 
distant from present Ada.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Private discrete type as index

[AG]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:b0435c$la5bg$1@ID-77047.news.dfncis.de...
> tmoran@acm.org wrote:
>
> >>   type x is limited private;
> >>   type test is array(x) of boolean;
> >   The "array" abstraction has certain characteristics, among them
> > sequential indexing.
>
> Why so? Array is just a mapping index->element, so if no index ranges
> required then the array index need not to be ordered (have "<" and "="),
> only "=" is required.

I suppose the answer will be that index ranges *are* required
by the array semantics (in Ada, at least). But, as you pointed out:

> Anyway a limited type is allowed to have both.

So, it should be able to meet the range requirements too.
At least if the provider of the type also provides the minimum
set of operations.

Re: Private discrete type as index

[tmoran]

> No. What I was originally trying to do was an abstraction as close
> to the array as possible (booleans do not matter of course - just
> something to put there). At the same time, I wanted to restrict
> control of the index to the package implementing it
> ...
> So, while I realise I can't (in Ada) provide things like "..",  I can
> provide +/-/</> operations of varying flavours on the index. This
> would keep most (not all, but most) of the array semantics in place.

   type x is new integer;
   type test is array(x range <>) of boolean;
   function "+"(left, right:x) return x;
   function "-"(left, right:x) return x;
   function "*"(left, right:x) return x;
   etc.
would give you quite a lot of control over the index.  Granted you
don't have "limited" and your user can get around you via type
conversion, but, assuming some discipline by your user, is that
amount of control still fatally inadequate for your purposes?
  I'm imagining for instance that "test" is really a giant array
on disk, and you page in parts depending on the currently live
index values.  Or "test" is some kind of tree or graph and "x" is
really a small record with bitfields telling where to go in the
structure. Then perhaps "x+1" means "take the right branch", etc.
A user's saying "test(x(123))" would be complete nonsense, but if
he starts with your supplied constants and only does your "arithmetic",
it could all make sense.

Re: Private discrete type as index

[AG]

<tmoran@acm.org> wrote in message news:adUV9.20206$hl1.1562@sccrnsc04...
> >> Why so? Array is just a mapping index->element, so if no index ranges
[ This was not my quote, I was responding to it ...]

> >I suppose the answer will be that index ranges *are* required
> >by the array semantics (in Ada, at least)

>   Perhaps to some people an array is a general map, but to me, and
> to at least the on-line glossaries I checked, it's not that general.
> Your abstraction appears to be a general mapping from elements of
> some set to booleans.

No. What I was originally trying to do was an abstraction as close
to the array as possible (booleans do not matter of course - just
something to put there). At the same time, I wanted to restrict
control of the index to the package implementing it (again, as
much as possible).

So, while I realise I can't (in Ada) provide things like "..",  I can
provide +/-/</> operations of varying flavours on the index. This
would keep most (not all, but most) of the array semantics in place.
Unfortunately, this appears to be impossible.

  Type "x" might be character strings and
> Test(x) True iff a symbol table has seen that string before.  That's
> a perfectly good map, but, IMHO, not something well modeled as an array.
>   My point is that your abstract object doesn't match the idea of
> "array" sufficiently well, and thus probably shouldn't be implemented
> with an array.

Re: Private discrete type as index

[AG]

<tmoran@acm.org> wrote in message news:Im8W9.33333$1q3.5319@sccrnsc01...
> > No. What I was originally trying to do was an abstraction as close
> > to the array as possible (booleans do not matter of course - just
> > something to put there). At the same time, I wanted to restrict
> > control of the index to the package implementing it
> > ...
> > So, while I realise I can't (in Ada) provide things like "..",  I can
> > provide +/-/</> operations of varying flavours on the index. This
> > would keep most (not all, but most) of the array semantics in place.
>
>    type x is new integer;
>    type test is array(x range <>) of boolean;
>    function "+"(left, right:x) return x;
>    function "-"(left, right:x) return x;
>    function "*"(left, right:x) return x;
>    etc.

The problem with this approach is that the following
is perfectly legal Ada (after you put it in a package or
so of course):

type x is new integer;
function "+"(left, right:x) return x;
a:x := 1 + 2;

Now, who exactly told the user of the package
that 1 & 2 are valid values for x? The declaration
"new integer" of course. Please note that in one of
my earlier posts in this thread this was exactly the
example I gave - replacing "new integer" with
"limited private". In fact, that's where it's coming
from in the first place...

> would give you quite a lot of control over the index.  Granted you
> don't have "limited" and your user can get around you via type
> conversion

As you could see, no [explicit] type conversions required.

> , but, assuming some discipline by your user, is that
> amount of control still fatally inadequate for your purposes?

Well, I thought that the philosophy of Ada was *not* to assume
any such thing on the part of a user. So, yes, that amount of
control is inadequate.