Re: Ragged Array Proposal

["Nick Roberts" <nickroberts@callnetuk.com>]

Ted Dennison <dennison@telepath.com> wrote in message
news:7sg24e$4oo$1@nnrp1.deja.com...
[...]
| > People: String_Array(1..3)(String(1..3),String(1..4),String(1..5));
|
| I'm not sure I like this example. Right now in Ada you would have to use
| explicit subtypes in any such declaration. But above you are using
| anonymous subtypes (eg: "String(1..3)"). I know creating a bunch
| of onetime subtypes might seem to be a pain, but it would restore
| consistency with the rest of the language.

I'm not quite sure what Ted is about here, but Ada has always allowed
stand-alone object definitions to have a subtype indication ('String(1..5)')
rather than just a subtype mark ('String_5'), and I cannot see any obvious
reason why the proposed 'array profile' shouldn't allow subtype indications.

| The only bad issue I still see is that its
| probably going to need a dope vector from hell to keep track of all the
| contraints of all its elements. But this isn't any different than the
| current situation with my array of string pointers.

An Ada implementation's internal representation of the profile would simply
be an array of whatever the implementation uses for stand-alone object's
subtypes (possibly requiring one extra level of indirection). This may be
considered to be a 'dope vector from Hell', but it would be hidden from the
programmer, and, since in practice most subtypes are static anyway, it would
often be optimised away anyway.

| I'm starting to like this proposal.

Thank you!

| I think the syntax does need still some work. For instance, can variant
| records be components too? What would one of those declarations look
| like? How about classwide tagged types?

I agree wholeheartedly. I am unsatisfied by both the syntax and the
nomenclature as I have it at present in my proposal. Even the name 'ragged
array' is not really appropriate. I would be very grateful for suggestions
of improvements.

| Also, if we do this, wouldn't the constrained subtype restriction on
| record fields start to look a bit restrictive?

Firstly, the specific rule is that record components must be definite,
rather than unconstrained (they can be unconstrained elementary types, each
type of which is assumed to occupy the same amount of memory regardless of
constraint).

Secondly, it is the purpose of record discriminants to parametise the
subtypes of record components. My proposal for ragged arrays is essentially
to provide a way (the 'array profile') to parametise the subtypes of the
components of an array. It is necessary that the subtypes of every component
of any definite array or record subtype is definite, since otherwise, in
general, it would be impossible to know how much memory to allocate for the
component (and grossly wasteful to allocate enough for any possible value).

Now, if a component in a record were allowed to have an indefinite subtype,
how could that subtype get constrained (to make it definite)? There would be
no point in inventing some mechanism to do so when such a mechanism already
effectively exists: discriminants.

-------------------------------------
Nick Roberts
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos
-------------------------------------