comp.lang.ada
 help / color / mirror / Atom feed
From: Matt Borchers <mattborchers@gmail.com>
Subject: Re: array from static predicate on enumerated type
Date: Fri, 12 Mar 2021 18:06:22 -0800 (PST)	[thread overview]
Message-ID: <6ca041f3-2669-4497-9548-2f17666702a6n@googlegroups.com> (raw)
In-Reply-To: <s2gqnf$vbs$1@gioia.aioe.org>

I pretty much agree with Dmitry on this.  The usefulness of this is very, very low without better support from the language itself.  However, Dmitry, if programmers should not consider a feature of a language as an option for a solution, then it begs the question on the quality of the language, quality of the compiler, or questions the abilities of caretakers of Ada.  Don't get me wrong, however, I think Ada is exceptional.

I thought I read that 'Pred and 'Succ do work as one would expect for the Predicated sub-type, but I did not try them as I did not need them.

I did read the entire rationale and 'First_Valid and 'Last_Valid would allow the programmer to create an array with a range that guarantees inclusion of all enumerated values of the statically predicated sub-type.  But, this leaves holes in the array as wasted memory.  My actual use case is hundreds of enumerated values and the sub-types have very few values each.  Think of a case like a Unicode table where you might want to classify characters into small non-contiguous groups and these character may be far apart from one another.

I do want a map or hash table, but in this case, I was hoping that Ada would handle the mapping for me such that I did not have to instantiate such a complexity for a simple example.  I was a bit surprised after discovering Static_Predicate that the Ada language syntax was essentially useless in dealing with it in a consistent way.

I like the idea of creating non-contiguous enumerated sub-types.  I've found that I often want to do it and must seriously consider design decisions like enumeration order that really should not be something that is that important to program design.  I think that if the language lets you define them, then the rest of the supporting syntax of the language should also support them even if there is a small penalty of a double look-up through a mapping table.

I had a simple case many years ago with Ada 95, I think, when I was implementing a checkers game.  I wanted an enumeration of 5 items for the piece the occupied a square.

type PIECE is ( EMPTY, RED, BLACK, RED_KING, BLACK_KING );
p : PIECE;

This was a nice order because I could use the language syntax to determine if piece was a King.

subtype KING is PIECE range RED_KING..BLACK_KING;
if p in KING then...

However, I had to write a function to determine if a piece was Red or Black and thus different calling syntax.  The other order option was:

type PIECE is ( EMPTY, RED, RED_KING, BLACK, BLACK_KING );

This order was nice because the language let me easily determine the Color of a piece.

subtype REDS is PIECE range RED..RED_KING;
subtype BLACKS is PIECE range BLACK..BLACK_KING;

if p in REDS then...

but I'd have to write a function to determine if a piece was a King and still different calling syntax.

Unfortunately, back then, the programmer couldn't have it both ways though it would've been very convenient.  It appears that Static_Predicate solves this problem because "in" is updated to work with the Predicate.  So if this works, why was it decided that the rest of the language syntax be inconsistent?  Surely a map table would have sufficed with a slight performance penalty, but for the sake of language consistency you let the programmer decide.  I can imagine an internally compiled map table would be much faster than the instantiation of the Map or Hash Container package.

Matt

  reply	other threads:[~2021-03-13  2:06 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 [this message]
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
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