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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,c469fdacc2f3302b
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,UTF8
Path: 
 g2news1.google.com!postnews.google.com!l12g2000prg.googlegroups.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Dynamic Variant Record Creation
Date: Tue, 16 Mar 2010 16:24:33 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <68c5e203-8757-463b-8124-145fa1e80041@l12g2000prg.googlegroups.com>
References: <Xns9D3D861E55DA0WarrensBlatherings@188.40.43.213>
	<c3fa9a0f-99c7-4fff-9310-7e4d769065db@s25g2000prd.googlegroups.com>
	<Xns9D3DA2FC9B9BWarrensBlatherings@188.40.43.213>
 <wccljdsnh48.fsf@shell01.TheWorld.com>
NNTP-Posting-Host: 207.200.116.71
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1268781873 8676 127.0.0.1 (16 Mar 2010 23:24:33
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 16 Mar 2010 23:24:33 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: l12g2000prg.googlegroups.com; posting-host=207.200.116.71;
	posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ
User-Agent: G2/1.0
X-HTTP-Via: HTTP/1.1 (Velocity/1.3.32 [uScMs f p eN:t cCMp s ]), HTTP/1.1
	spider-ntc-tb02.proxy.aol.com[CFC87022] (Prism/1.2.1), HTTP/1.1
	cache-ntc-ab07.proxy.aol.com[CFC87447] (Traffic-Server/6.1.5 [uScM])
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1;
	SV1; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:9619
Date: 2010-03-16T16:24:33-07:00
List-Id: <comp.lang.ada>

On Mar 16, 1:31=EF=BF=BDpm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Warren <ve3...@gmail.com> writes:
> > Of course. But it is not conceptually inconceivable to
> > check this at runtime and realize that the value I handed
> > out will work with what was provided. If not, then
> > raise an exception.
>
> Not inconceivable, I suppose, but that would be a huge language
> change. =EF=BF=BDIt would require totally rethinking the overload
> resolution rules, because currently there's a fundamental
> principle that the type of an aggregate is determined by
> context (ignoring the components), and once that type is
> known, the component expressions are resolved knowing
> their types.
>
> I really don't think you want to do overload resolution at
> run time.

Actually, I don't think overload resolution would be an issue, as long
as the aggregate (or at least the components that are in variant
parts) is specified using named associations.  As you said, the
information about the components isn't used to determine the expected
type of the aggregate.  Once the type is determined from context, the
names of the variant components would be enough to determine which
variants must be present, and therefore what the allowable values of
the governing discriminant(s) are.  (And, of course, if two component
names are specified that cannot exist at the same time, it's already
illegal.)  However, this wouldn't work if positional notation is used,
and this inconsistency (discriminants must be static if components are
in positional notation but need not be if they use named associations)
would be enough reason for me to say this is a bad idea, if I didn't
already think it was, which I do.

                                    -- Adam