Question about default discriminants and mutable objects.
in [ADA]
|
From: Peter C. Chapin on 5 May 2010 20:41 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. Thanks! Peter
From: Randy Brukardt on 5 May 2010 21:26 "Peter C. Chapin" <pcc482719(a)gmail.com> wrote in message news:4be20f28$0$2431$4d3efbfe(a)news.sover.net... .... > 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 know; I know the idea come from Ada 83, but I have no idea why they chose that. It's been a long-time annoyance in Ada that these two concepts are intertwined. (It's very much like the annoying requirement that a protected function do only read-only things to the protected object, while a protected procedure has to be assumed to modify the protected object (neither are true in general, of course).) > 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 personally think it was a mistake that this implementation was allowed, since it makes many useful discriminated types impossible or excessively expensive in space. Janus/Ada allocates discriminant-dependent components to size, and thus reallocates the components if a discriminant is changed. That of course has other problems (mostly in overhead if the objects are assigned often). Most everyone disagrees with my position on this, the reasoning being that the extra memory allocation overhead isn't justified on real-time systems. Probably there is some happy medium using a combination of both implementations (clearly some real-time systems couldn't allow a reallocating implementation, but that is what we have pragma Restrictions for; for other uses, a more flexible implementation is better, IMHO). Randy.
From: Gene on 5 May 2010 23:25 On May 5, 8:41 pm, "Peter C. Chapin" <pcc482...(a)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. > > Thanks! > > Peter I don't have any special knowledge, but I've always satisfied my own curiosity about this with the rationale that if there were a way to create a value with an uninitialized discriminant, that value would literally have no type. This contrasts with uninitialized values that still do have well-defined types: An uninitialized Integer still has type Integer. The discriminant convention as-is prevents values with no type from occurring. If there is no default descriminant, then the discriminant must be established by initialization. OTOH, if there is a default, an uninitialized variable of the discrimiated type can be declared, and its type will be well-defined, even though its value may not be.
From: Gene on 6 May 2010 00:07 On May 5, 8:41 pm, "Peter C. Chapin" <pcc482...(a)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.
From: AdaMagica on 6 May 2010 00:56
Gene, you guessed quite well. See Ada 83 Rationale http://archive.adaic.com/standards/83rat/html/ratl-04-07.html#4.7 and especially 4.7.4. |