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,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c63aa81a67eceb8f X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: Ragged Array Proposal Date: 1999/09/24 Message-ID: <37ebe8e5@eeyore.callnetuk.com>#1/1 X-Deja-AN: 529200892 References: <37e7c08e@eeyore.callnetuk.com> <7satei$e2q$1@nnrp1.deja.com> <37EA4E91.1D4D1FC@averstar.com> <37eaa24b@eeyore.callnetuk.com> <7sg24e$4oo$1@nnrp1.deja.com> X-Original-NNTP-Posting-Host: da132d205.dialup.callnetuk.com X-Trace: 24 Sep 1999 22:11:01 GMT, da132d205.dialup.callnetuk.com X-MSMail-Priority: Normal X-Priority: 3 Newsgroups: comp.lang.ada X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Date: 1999-09-24T00:00:00+00:00 List-Id: Ted Dennison 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 -------------------------------------