comp.lang.ada
 help / color / mirror / Atom feed
From: Gene <gene.ressler@gmail.com>
Subject: Re: Question about default discriminants and mutable objects.
Date: Wed, 5 May 2010 21:07:30 -0700 (PDT)
Date: 2010-05-05T21:07:30-07:00	[thread overview]
Message-ID: <866a9a72-1f76-480d-b860-57e66ae155c0@d39g2000yqa.googlegroups.com> (raw)
In-Reply-To: 4be20f28$0$2431$4d3efbfe@news.sover.net

On May 5, 8:41 pm, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> Hopefully I can ask this question clearly...
>
> I understand that an instance of a type with default discriminants can be
> mutated (here I mean have its discriminant changed) via assignment. It seems
> like the most effective way for a compiler to support that ability is to
> always allocate enough memory for the object to account for all possible
> discriminant values. Mordechai Ben-Ari pretty much says this explicitly in
> his book "Ada for Software Engineers."
>
> I also understand that an instance of a type without default discriminants
> can't be mutated in this way (that is, by assignment). If a new value is
> assigned to the object with the wrong discriminant the result is
> Constraint_Error. This would allow the compiler to allocate just the memory
> necessary for that particular discriminant value used to initialize the
> object since there would never be a (successful) attempt to stuff a larger
> object into that space.
>
> It seems like conceptually the issue of default discriminants and mutability
> (in the sense I mean here) are independent. One could imagine some currently
> non-existent syntax that would allow the programmer to mark a type
> declaration so that the compiler allowed discriminant values to be changed
> via assignment without leaning on the mechanism of default discriminants.
> Furthermore one could imagine treating default discriminants as 100%
> syntactic sugar and not endowing them with any special semantics regarding
> mutability.
>
> Okay, so my question is: what was the rationale behind combining the notion of
> default discriminants with the notion of mutability? Is there some subtle
> technical reason why they must go together? I don't have pressing need to
> know... I'm curious and I'm trying to deepen my understanding of this topic.
>
I don't have any special knowledge, and I also believe there is no
really good reason for the connection.

But I've always satisfied my own curiosity about this with the
rationale that it's all about declarations that look like

x : Foo;

where Foo is a discriminated type.

For Foo to be well-defined, it must have a default descriminant
value.  Otherwise it is no type at all.

Yet the syntax here connotes that any value of type Foo ought to be
assignable to x in the future.  It would be an opaque gotcha if a
future assignment to x with a value having other than the default
discriminant caused a run-time exception.

The conclusion is that x ought to be mutable.  Viola!  Discriminated
types with default discriminant values are mutable.

And if you're going to admit non-mutable discriminant types at all,
then it's something like logical for all the rest to be these.

Tortured, I agree...  One can almost hear the design-by-committee in
progress.




  parent reply	other threads:[~2010-05-06  4:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-06  0:41 Question about default discriminants and mutable objects Peter C. Chapin
2010-05-06  1:26 ` Randy Brukardt
2010-05-06  4:07 ` Gene [this message]
2010-05-06  4:56   ` AdaMagica
2010-05-06 14:59     ` Adam Beneschan
2010-05-07  0:47     ` Peter C. Chapin
2010-05-07  2:07       ` Randy Brukardt
2010-05-07 12:35         ` Robert A Duff
2010-05-06 15:15 ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox