Re: array from static predicate on enumerated type

["Randy Brukardt" <randy@rrsoftware.com>]

"Matt Borchers" <mattborchers@gmail.com> wrote in message 
news:8f7d1d02-c5f0-4ed5-8003-09c6f467d63cn@googlegroups.com...
> On Friday, March 12, 2021 at 11:55:54 PM UTC-5, Randy Brukardt wrote:
>> Just don't use them with obsolete data structures. :-)
>
> I can't tell if you are you being facetious?  If not, can you give me some 
> reasons on
>why you think arrays are obsolete data structures?  To me, they remain one 
>of the
>basic building blocks of all programs.

If you're talking *representation*, then surely arrays are the root of 
everything. But a general purpose programming language should hide 
representation issues as much as possible. For most uses, how a data 
structure is implemented is irrelevant; you want to ask for the fundamental 
data.structure that you need and let the implementation chose the best 
implementation to meet your needs.

And an array is not a fundamental data structure: those are bags and 
sequences and maps (and trees and graphs, but those aren't relevant here). 
Arrays have features of all of these, as well as some others -- they're not 
a fundamental data structure at all.

Moreover, Ada in particular merges in additional features that have little 
to do with data structures, and end up with a mixed up mess where one gets 
surprises from super-null arrays and arrays whose lower isn't 'First and 
holey arrays and other such nonsense.

For instance, the primary reason that Ada cannot have holey arrays is 
because of the slice (mis)feature, in particular because a slice can be 
assigned and (worse) passed as an in out parameter. If one has holey arrays, 
one also would expect to have holey slices (else the language would be quite 
inconsistent). But implementing a holey slice is problematic. For parameter 
passing, pretty much the only way to implement that would be to provide a 
call-back subprogram with every parameter that knows how to write each index 
of the slice. But that would be a classic distributed overhead -- it would 
be incurred for *every* array parameter since one can always create a holey 
slice of an array -- even of a type that is not itself holey. That would 
make passing strings and other arrays *much* more expensive.

Consider the following (illegal) example:

     subtype Trouble is Positive with Static_Predicate => Trouble in 1 | 2 | 
8 | 10;

     Message : String := "Barb Judge!"

     Put_Line (Message(Trouble)); -- Illegal.

If this was legal, the Put_Line would have to output "Bad!". Now, you can 
probably think of ways to implement such a slice, but they'd require copying 
it at the call site. That would work for Put_Line of a few characters, but 
it could be too expensive for larger arrays. Moreover, consider 
Ada.Strings.Overwrite:

     Ada.Strings.Overwrite (Message(Trouble), Position => 2, "ooo");

This would be asking the compiler to somehow figure out that it needs to 
write the 2nd, 8th, and 10th characters of Message. And still be able to 
handle the more normal kinds of slices as well.

And then (if you want a completely consistent language), remember that array 
components can be by-reference types, that are not allowed to be copied when 
passed as parameters.

The point is that holey arrays are a massive can of worms, and its 
impossible to have a consistent language if discontiguous subtypes exist. 
Tucker likes to say that sometimes language design is like a bump under a 
carpet -- you can move the bump around, but you can't get rid of it without 
ripping out the carpet and starting over (with a different language design). 
This is one of those cases.

                                      Randy.