Array slices and types

On Aug 21, 1:53 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 21 Aug 2008 08:26:26 +0300, Niklas Holsti wrote:
> > But doesn't this example show that it would be useful to have 'Base
> > also for array types?
>
> For any type, actually.
>
> Consider this language design fault:
>
> procedure Initialize (X : in out S) is
> begin
> Initialize (T (X));
> ... -- My stuff
> end Initialize;
>
> A call to Initialize should be done automatically, but it is not. So the
> parent of S must be explicitly specified and known to all descendant. This
> is a really *bad* thing:
>
> package Foo is
> type S is new T with private;
> private
> type S is new Private_Decendant_Of_T with ...;
> end Foo;
>
> What would happen if Private_Decendant_Of_T overrode Initialize of T? The
> result would be an inability to publicly derive from S any new types if
> Initialize should be extended!
>
> S'Base could mend it:
>
> procedure Initialize (X : in out S) is
> begin
> (S"Base (X)).Initialize; -- Call to parent whatever it be
> ... -- My stuff
> end Initialize;

Sorry, Dmitry, but if you'll pardon the expression, you're a little
off-base here. S'Base and S are subtypes of the same *type*. They
may be different subtypes (have different constraints), but they're
the same type. You're asking for an attribute that would give you a
different type. There may be merit in having such an attribute (I
haven't looked into it closely), but calling it 'Base would be a bad
idea. S'Parent might be better.

Niklas is asking for S'Base to be the unconstrained array subtype of
the (possibly constrained) array subtype S. It would still fit into
the definition of 'Base (3.5(15)). I'm not sure why this wasn't
defined for array subtypes, or for any other type that could have
discriminants; offhand I don't see how this would cause any problems.

-- Adam

On Thu, 21 Aug 2008 07:44:29 -0700 (PDT), Adam Beneschan wrote:

> Sorry, Dmitry, but if you'll pardon the expression, you're a little
> off-base here. S'Base and S are subtypes of the same *type*.

No need to excuse, you are right, I don't see any semantic difference
between subtypes of "same" type and derived tagged types. Consequently, I
don't think it is worth to further maintain such difference in the
language.

> They
> may be different subtypes (have different constraints), but they're
> the same type. You're asking for an attribute that would give you a
> different type.

Yep, for that matter, tag is merely a constraint put on T'Class. Ada 83
model is capable to incorporate OO! We always knew that! (:-))

> There may be merit in having such an attribute (I
> haven't looked into it closely), but calling it 'Base would be a bad
> idea. S'Parent might be better.

Integer'Parent were Universal_Integer, I guess (:-))

> Niklas is asking for S'Base to be the unconstrained array subtype of
> the (possibly constrained) array subtype S. It would still fit into
> the definition of 'Base (3.5(15)). I'm not sure why this wasn't
> defined for array subtypes, or for any other type that could have
> discriminants; offhand I don't see how this would cause any problems.

I think that the reason was that S'Base was thought as a very low-level
thing, something like the least constrained type of the *same* internal
representation. For unconstrained arrays the representation is likely not
the same, they might have a dope. For other types nobody seemingly cared.
(:-))

IMO, if S'Base need to be extended, then that would require a bit firmer
foundation than the above.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 20 Sie, 22:45, Adam Beneschan <a...@irvine.com> wrote:

> Do you really need a new *type*, as opposed to:
>
> * *subtype Name is String (1 .. 10);
>
> ???

Good question. If I make it a subtype, then I have no protection
against mixing First_Name with Device_Name with File_Name with
Signal_Name with Any_Other_Name - and that would defeat the whole
purpose of defining them.

Consider:

declare

subtype First_Name is String (1 .. 4);
subtype Device_Name is String (1 .. 4);

Someone : First_Name := "Adam";
Something : Device_Name := "usb1";

begin
Someone := Something; -- oops
end;

That's why I was thinking about distinct types. I'm OK with type casts
when assigning them from regular String.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

"Adam Beneschan" <adam@irvine.com> wrote in message
news:fc112b42-285c-4ed5-ae78-34be4e60f6df@i20g2000prf.googlegroups.com...
> On Aug 21, 1:53 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 21 Aug 2008 08:26:26 +0300, Niklas Holsti wrote:
>> > But doesn't this example show that it would be useful to have 'Base
>> > also for array types?
>>
>> For any type, actually.
>>
>> Consider this language design fault:
>>
>> procedure Initialize (X : in out S) is
>> begin
>> Initialize (T (X));
>> ... -- My stuff
>> end Initialize;
>>
>> A call to Initialize should be done automatically, but it is not. So the
>> parent of S must be explicitly specified and known to all descendant.
>> This
>> is a really *bad* thing:
>>
>> package Foo is
>> type S is new T with private;
>> private
>> type S is new Private_Decendant_Of_T with ...;
>> end Foo;
>>
>> What would happen if Private_Decendant_Of_T overrode Initialize of T? The
>> result would be an inability to publicly derive from S any new types if
>> Initialize should be extended!
>>
>> S'Base could mend it:
>>
>> procedure Initialize (X : in out S) is
>> begin
>> (S"Base (X)).Initialize; -- Call to parent whatever it be
>> ... -- My stuff
>> end Initialize;
>
> Sorry, Dmitry, but if you'll pardon the expression, you're a little
> off-base here. S'Base and S are subtypes of the same *type*. They
> may be different subtypes (have different constraints), but they're
> the same type. You're asking for an attribute that would give you a
> different type. There may be merit in having such an attribute (I
> haven't looked into it closely), but calling it 'Base would be a bad
> idea. S'Parent might be better.

I tried to propose such a thing for Ada 2005, but it didn't work out. There
isn't necessarily a single type that is the parent, unless you break
privacy. Specifically:

package P is
type New_Type is new Some_Base with private;
procedure Some_Operation (Obj : in out New_Type; Parent : in
New_Type'Parent);
private
type New_Type is new Some_Derived with record ...
end P;

In this case, what does New_Type'Parent give you in the body? We'd want it
to resolve to Some_Derived. But a client of P can't see the full declaration
(and shouldn't be able to depend on it), and thus P.New_Type'Parent would
have to resolve to Some_Base.

So far, we can live with this. But now consider the completion to
Some_Operation: the body would use the same parameter types in order to
conform, but the *meaning* of the second parameter would be different to
clients and the body. Oops. One could ban using this attribute in such
specs, but that looks like a nasty wart (as bad as the original one). Thus,
we didn't get a 'Parent attribute.

> Niklas is asking for S'Base to be the unconstrained array subtype of
> the (possibly constrained) array subtype S. It would still fit into
> the definition of 'Base (3.5(15)). I'm not sure why this wasn't
> defined for array subtypes, or for any other type that could have
> discriminants; offhand I don't see how this would cause any problems.

It does cause problems, and they're pretty severe as I recall. After all,
Ada 83 allowed 'Base on everything (but only as a prefix of another
attribute). That was removed in Ada 95 because of problems. But I can't
remember what they were precisely. Sorry about that.

Randy.

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
news:5886ab95-8744-4b72-b911-e4cb8889c7e7@d1g2000hsg.googlegroups.com...
> Consider this:
>
> type Name is new String (1 .. 10);
>
> N : Name;
>
> Some_String : String := "abc";
>
> How can I assign Some_String to the beginning slice (ie. to the first
> three characters) of N?
> Everything that I can think of (short of copying characters
> individually) hits the type compatibility problem.

If you can change the definition of Name to:

subtype Name is String( 1 .. 10 );

Then of course you can use:

N( 1 .. 3 ) := Some_String( 1 .. 3 );

But that doesn't sound like what you're looking for.

Regards,
Steve

>
> --
> Maciej Sobczak * www.msobczak.com * www.inspirel.com
>
> Database Access Library for Ada: www.inspirel.com/soci-ada