From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2afac1a4161c7f35,start
X-Google-Attributes: gid103376,public
From: chipr@niestu.com (Chip Richards)
Subject: Two simple language questions
Date: 1998/01/07
Message-ID: <68uq34$7tk@tomquartz.niestu.com>#1/1
X-Deja-AN: 313494577
Content-Type: text/plain; charset=us-ascii
Organization: NiEstu, Phoenix AZ USA
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1998-01-07T00:00:00+00:00
List-Id: <comp.lang.ada>


I hope.

First: It says in the Intro to Ada 9X, in Chapter 2, "General access types can
also be used to program static ragged arrays as for example a table of
messages of different lengths."  Now, I know this has been asked before, some
time ago, but I cannot seem to locate the text of the exchange.  What I want
to know is, exactly what is the syntax for doing this?  I've so far used
allocators, i.e.:

   strs:  StringArr :=
   (
       new string'("Line 1"),
       new string'("Line 2"),
       ...
       new string'("Line the Last")
   );

Which works great, but isn't exactly the "static" ragged arrays mentioned in
the intro.  What I want is something like "Line 1"'access, but of course that
doesn't work, nor have any of the sixteen-umpty variations that I've tried.
The RM just said that in X'access, X must be an aliased view of an object.
Well, hmph.  Hep me, hep me, please.

Second, a bit more of a philosophy question, I think.  I've had a couple of
occasions where I've created Ada95 child packages, and in those packages, I've
wanted to extend enumeration types defined by the parent.  As an example:

   type Colors is ( Red, Green, Blue );

And in the child, I'd like to be able to say

   type More_Colors is new Colors with ( Yellow, Purple );

Except, of course, that isn't Ada.  So, what's considered the best approach to
this sort of thing?  Just re-list the constants of the parent type, and add
the new constants into the list?  Seems a bit repetetive and error-prone to
me, and I was just wondering if I'd missed someone proposing a more elegant
solution.  Or am I really off the rails and missing something totally obvious?

Thanks for your time!

-- 
Chip