comp.lang.ada
 help / color / mirror / Atom feed
From: Shark8 <onewingedshark@gmail.com>
Subject: Re: array from static predicate on enumerated type
Date: Wed, 17 Mar 2021 08:08:56 -0700 (PDT)	[thread overview]
Message-ID: <b748dcdd-b219-456a-81f4-118c743bb98bn@googlegroups.com> (raw)
In-Reply-To: <a173284c-ed52-4de5-8df7-6a83ede65435n@googlegroups.com>

On Tuesday, March 16, 2021 at 10:05:31 PM UTC-6, Matt Borchers wrote:
> So, I understand why holey arrays are problematic and I'm not asking for holey arrays here.
> I was looking for elegant solution around the fact that Ada intentionally does not provide a reasonable answer to 'First, 'Last, etc. when used on enumerated sub-types with a Predicate.
As I attempted to explain up-thread, the issue you are looking at *IS* the issue with holey arrays.

> In my cases, I have a lot of small (less than 5 rows and columns) multi-dimensional static data. It appears instantiating a Map and populating it at program start-up is the recommended solution. However, it sure seems to me that a static constant array of data is ideal because loading the Map cannot be guaranteed correct by the compiler whereas a table would be.
Since you want holes, you could use the abstraction to your benefit:

    Subtype Letters is Character range 'A'..'Z';
    Subtype Curved  is Letters
      with Static_Predicate => Curved in 'B' | 'C' | 'D' | 'G' | 'J';
    Type Curved_2 is ('B', 'C', 'D', 'G', 'J')
       with Size => Letters'Size;
    For Curved_2 use (
       'B' => Character'Pos( 'B' ),
       'C' => Character'Pos( 'C' ),
       'D' => Character'Pos( 'D' ),
       'G' => Character'Pos( 'G' ),
       'J' => Character'Pos( 'J' )
      );

    --------------
    --Private/Body part
    Actual_Map : Constant Array (Curved_2) of Integer;

    -- In Body
    Function Do_Map(C : Character) return Integer is
        Function Convert is new Ada.Unchecked_Conversion(
           Source => Character,
           Target => Curved_2
          );
    Begin
        Return (if C in Curved then Actual_Map(Convert(C))
                     --ELSIF other_condition then Another_Map(Another_Convert(C))
                     else raise Constraint_Error with "Invalid Index: '"& C &"'.");
    End Do_Map;

An array might be "ideal", but only if the thing you're indexing by is contiguous, otherwise you literally ARE asking for a slice with holes.
Another option you might have is this:

    Table : Array (Character range 'A'..'Z') of Integer:= (Others => 12);
    K : Integer := 7
      with Address => Table('K')'Address;
> 
> It feels like an unfinished addition or incomplete feature to actively prevent 'First, 'Last, etc. from returning something reasonable about the sub-type in question. Return SOMETHING, even if it pertains to the parent type, and let the programmer decide how it can be useful to them. Using my LETTERS and CURVED_LETTERS example, I still don't see why the following would be problematic: 
> 
> A <= LETTERS'First 
> K <= LETTERS'Last 
> 11 <= LETTERS'Length 
> 1 <= LETTERS'Pos(B) 
> 10 <= LETTERS'Pos(J) 
> 
> B <= CURVED_LETTERS'First 
> J <= CURVED_LETTERS'Last 
> 5 <= CURVED_LETTERS'Length 
> 0 <= CURVED_LETTERS'Pos(B) 
> 4 <= CURVED_LETTERS'Pos(J) 
> 
> I didn't address 'Succ and 'Pred, but these also seem reasonable.
Read my post upthread, then Randy's, and you'll see that the absence of these features is tied to the holy-array/-slice problem.
Think about how difficult it would be to define multidimensional slices, which by their nature must be holey, and in a manner conducive to "efficiency" (in the C programmer's meaning).

> Again, I don't know the inner workings of the compiler, but these responses (above) for CURVED_LETTERS seem like reasonable values related to the sub-type that the compiler could handle easily allowing programmers who might want to write: 
> 
> type ARR(CURVED_LETTERS) of BOOLEAN; 
> 
> but for strict legality purposes have to suffice with: 
> 
> type ARR(CURVED_LETTERS'Pos(CURVED_LETTERS'First)..CURVED_LETTERS'Pos(CURVED_LETTERS'Last)) of BOOLEAN; 
> 
> It sure is ugly and some of you will surely yell, but we can do this now with a regular enumerated type and so it should be consistent for an enumerated sub-type. At least creating an array from this type can be do-able with access to these attributes and it can also be verified correct by the compiler.
Do you want such an array to hold 256 bits? One for each character with a CONSTRAINT_ERROR on bad indexing? (Meaning some sort of automatically generated function that is invisibly integrated into this object.)
Or are you wanting an array with holey indexes, collapsed spacewise, so that it's only 5 bits?
These are the questions which must be answered to even start to consider the issues at hand.

  parent reply	other threads:[~2021-03-17 15:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 20:49 array from static predicate on enumerated type Matt Borchers
2021-03-12 21:22 ` Egil H H
2021-03-12 22:16 ` Jeffrey R. Carter
2021-03-12 22:41 ` Dmitry A. Kazakov
2021-03-13  2:06   ` Matt Borchers
2021-03-13  4:55     ` Randy Brukardt
2021-03-15 14:16       ` Matt Borchers
2021-03-15 17:53         ` Shark8
2021-03-16  6:58         ` Randy Brukardt
2021-03-13  8:04     ` Dmitry A. Kazakov
2021-03-15 14:11       ` Matt Borchers
2021-03-15 17:48         ` Shark8
2021-03-15 20:25           ` Dmitry A. Kazakov
2021-03-16 13:27             ` Shark8
2021-03-16 14:25               ` Dmitry A. Kazakov
2021-03-17  4:05                 ` Matt Borchers
2021-03-17  7:08                   ` Dmitry A. Kazakov
2021-03-17 18:44                     ` Matt Borchers
2021-03-17 19:41                       ` Dmitry A. Kazakov
2021-03-18  1:30                         ` Matt Borchers
2021-03-18  8:20                           ` Dmitry A. Kazakov
2021-03-19  0:10                             ` Matt Borchers
2021-03-19  8:00                               ` Dmitry A. Kazakov
2021-03-18 10:15                           ` Niklas Holsti
2021-03-18 10:47                             ` AdaMagica
2021-03-18 11:26                               ` Dmitry A. Kazakov
2021-03-19  0:34                             ` Matt Borchers
2021-03-19  0:49                               ` Jeffrey R. Carter
2021-03-23  1:07                                 ` Matt Borchers
2021-03-23  3:43                                   ` Randy Brukardt
2021-03-22 19:09                               ` Niklas Holsti
2021-03-17 15:08                   ` Shark8 [this message]
2021-03-17 19:08                     ` Matt Borchers
2021-03-17 20:41                       ` Shark8
2021-03-18  1:04                         ` Matt Borchers
2021-03-18 14:25                           ` Shark8
2021-03-18 23:36                             ` Matt Borchers
2022-03-16  0:38             ` Thomas
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox