Help sought to fix RM Pre 21 (multiple assignment)
Quote from Hugh on November 26, 2019, 3:55 pmQuote from dandl on November 26, 2019, 12:44 am
E' := ELLIPSE(THE_A(E), THE_A(E) + 1.0), E'' := ELLIPSE(THE_A(E') + 2.0, THE_B(E'));The expression coloured red violates the type constraint for ELLIPSE , so if E' is of type ELLIPSE, then it is impossible for it to acquire or stand for the (non-existent) value of that expression.
This is merely an arrangement of symbols, part of the expansion of shorthands in step a. It will never be executed, so it cannot fail a type constraint.
Quote from dandl on November 26, 2019, 10:54 pmQuote from Hugh on November 26, 2019, 3:55 pmQuote from dandl on November 26, 2019, 12:44 am
E' := ELLIPSE(THE_A(E), THE_A(E) + 1.0), E'' := ELLIPSE(THE_A(E') + 2.0, THE_B(E'));The expression coloured red violates the type constraint for ELLIPSE , so if E' is of type ELLIPSE, then it is impossible for it to acquire or stand for the (non-existent) value of that expression.
This is merely an arrangement of symbols, part of the expansion of shorthands in step a. It will never be executed, so it cannot fail a type constraint.
The expansion of shorthands is part of the model, so they conceptually execute -- and thus the model currently specifies that the type constraint fail -- even if some implementation deviates from the model.
Quote from Dave Voorhis on November 26, 2019, 11:09 pmQuote from dandl on November 26, 2019, 10:54 pmQuote from Hugh on November 26, 2019, 3:55 pmQuote from dandl on November 26, 2019, 12:44 am
E' := ELLIPSE(THE_A(E), THE_A(E) + 1.0), E'' := ELLIPSE(THE_A(E') + 2.0, THE_B(E'));The expression coloured red violates the type constraint for ELLIPSE , so if E' is of type ELLIPSE, then it is impossible for it to acquire or stand for the (non-existent) value of that expression.
This is merely an arrangement of symbols, part of the expansion of shorthands in step a. It will never be executed, so it cannot fail a type constraint.
The expansion of shorthands is part of the model, so they conceptually execute -- and thus the model currently specifies that the type constraint fail -- even if some implementation deviates from the model.
Rubbish. The expansion of shorthands is a transformation performed before the final form of the code is known, and before (in the general case) the values of the expressions it deals with are known. All of steps a, b and c have the effect of rewriting the code. Nothing is evaluated until step c. That's what it says.
Quote from dandl on November 27, 2019, 12:17 amQuote from Dave Voorhis on November 26, 2019, 11:09 pmQuote from dandl on November 26, 2019, 10:54 pmQuote from Hugh on November 26, 2019, 3:55 pmQuote from dandl on November 26, 2019, 12:44 am
E' := ELLIPSE(THE_A(E), THE_A(E) + 1.0), E'' := ELLIPSE(THE_A(E') + 2.0, THE_B(E'));The expression coloured red violates the type constraint for ELLIPSE , so if E' is of type ELLIPSE, then it is impossible for it to acquire or stand for the (non-existent) value of that expression.
This is merely an arrangement of symbols, part of the expansion of shorthands in step a. It will never be executed, so it cannot fail a type constraint.
The expansion of shorthands is part of the model, so they conceptually execute -- and thus the model currently specifies that the type constraint fail -- even if some implementation deviates from the model.
Rubbish. The expansion of shorthands is a transformation performed before the final form of the code is known, and before (in the general case) the values of the expressions it deals with are known. All of steps a, b and c have the effect of rewriting the code. Nothing is evaluated until step c. That's what it says.
I'm not sure what "a transformation performed before the final form of the code is known" means, but per the current definitions, the problem is real and Hugh has confirmed it.
Quote from AntC on November 26, 2019, 8:31 pm
OK here's a nice knock-down argument (to quote Lewis Carroll, who seems to be looking over my shoulder at this discussion).
- Suppose a scalar type with two relation-valued components (among others);
- Suppose the type has a constraint declared on those components that enforces some referential integrity between them.
- How is that different to the two-relvar example in RM Pre 23 Note?
- And how do you propose to keep that constraint "inviolate" for an attempt to update each component as separate
THE_x( ) := ...assignments within an MA?
(Let's say the same MA is also assigning to anELLLIPSEcomponent.)
The difference is that now the "referential integrity" is full part and parcel of the type constraint.
How to deal with it is as per the same procedure already suggested to ***eliminate*** the invocation of the intermediate selector (so the ***type*** constraint will only be checked after all component values have been "put in place").
Quote from Dave Voorhis on November 27, 2019, 6:54 amQuote from dandl on November 27, 2019, 12:17 amQuote from Dave Voorhis on November 26, 2019, 11:09 pmQuote from dandl on November 26, 2019, 10:54 pmQuote from Hugh on November 26, 2019, 3:55 pmQuote from dandl on November 26, 2019, 12:44 am
E' := ELLIPSE(THE_A(E), THE_A(E) + 1.0), E'' := ELLIPSE(THE_A(E') + 2.0, THE_B(E'));The expression coloured red violates the type constraint for ELLIPSE , so if E' is of type ELLIPSE, then it is impossible for it to acquire or stand for the (non-existent) value of that expression.
This is merely an arrangement of symbols, part of the expansion of shorthands in step a. It will never be executed, so it cannot fail a type constraint.
The expansion of shorthands is part of the model, so they conceptually execute -- and thus the model currently specifies that the type constraint fail -- even if some implementation deviates from the model.
Rubbish. The expansion of shorthands is a transformation performed before the final form of the code is known, and before (in the general case) the values of the expressions it deals with are known. All of steps a, b and c have the effect of rewriting the code. Nothing is evaluated until step c. That's what it says.
I'm not sure what "a transformation performed before the final form of the code is known" means, but per the current definitions, the problem is real and Hugh has confirmed it.
He just assumes he is free to perform whatever "compiler magic" he is used to from other compilers doing it for other languages, and doesn't realise that apparently the intent of steps a.-d. is that if "rearranging terms" is not part of any of those steps, he is ***not*** free to perform that magic. I presume he knows what they say of assume.
Quote from Erwin on November 27, 2019, 8:20 am
He just assumes he is free to perform whatever "compiler magic" he is used to from other compilers doing it for other languages, and doesn't realise that apparently the intent of steps a.-d. is that if "rearranging terms" is not part of any of those steps, he is ***not*** free to perform that magic. I presume he knows what they say of assume.
I am satisfied that the operations I have proposed are of the same kind is those mentioned in TTM and the TD spec and achieve similar ends.
I've now resolved this question to my satisfaction, and I find that I've lost interest in persuading others to my point of view. Unless someone has something new to contribute, I think my work is done.
But do read the section in the TD spec if you haven't already. I think Hugh should have re-read that and quoted from it before he asked his question. My solution is remarkably similar.
Quote from Dave Voorhis on November 26, 2019, 5:06 pmQuote from Hugh on November 26, 2019, 3:43 pmQuote from Dave Voorhis on November 25, 2019, 3:09 pmQuote from Hugh on November 25, 2019, 2:33 pmAlso, we believe very strongly that assignment to a possrep component is merely shorthand (as in OO languages) and we think that is the right way to express the semantics.
The TTM approach -- which defines assignment to a possrep component as shorthand for invoking a selector -- has no equivalent in typical object-oriented languages.
In typical object-oriented languages, the closest equivalent to assignment to a possrep component is either invocation of a method that changes instance state (such a method is often called a 'setter', because it sets the value of an instance's member variable) or direct assignment to an instance's member variable. I'm not aware of any object oriented language in which assignment to a member variable is shorthand for invoking a constructor (which is the nearest equivalent to a selector), though an object oriented language could conceivably be made that would do that.
Or did you mean something different by "as in OO languages"?
Well, for what it's worth, the SQL standard used a similar definition in the 1998 edition and I'm not aware of that having changed since.
Let P be a POINT object in some OO language, such that P.X := 3.0 results in P's X value becoming 3.0 while its Y value remains unchanged. Couldn't that be short for P := POINT(3.0, P.Y)? I understand that the RHS there is an invocation of a constructor, but does that make an material difference? (Please excuse my ignorance.)
Hugh
It depends on how "material difference" is defined.
Given, say, variables P and Q which are references to distinct instances of POINT(2.0, 4.0), executing P.X := 3.0 and Q := new POINT(3.0, Q.Y) will result in P.X and Q.X both being equal to 3.0, and P.Y and Q.Y both remaining equal to 4.0.
From that point of view, they are not materially different.
However, after the assignments, P references the same instance it did before but Q references a different instance. Memory was allocated for Q's new instance of POINT, but no new memory was allocated for P.X := 3.0. Furthermore, the accessible methods of a class instance provide an interface to what might be encapsulated (and possibly hidden) additional functionality, such as (for example) POINT might internally maintain a historical log of every assigned X or Y value (the history presumably being accessible via some POINT method.) In that case, P might reference an instance with a lengthy history of assignments to X and Y. Being newly constructed, the instance referenced by Q would contain no such history.
From that point of view, they are materially different.
Thank you, Dave. Twenty years ago I sort of knew all that but I suppose I haven't retained it because I never actually used such languages.
So OO assignment to component isn't equivalent to the proposed longhand, and that's because of an ingredient that TTM abjures (pointers).
Hugh
Quote from dandl on November 26, 2019, 10:54 pmQuote from Hugh on November 26, 2019, 3:55 pmQuote from dandl on November 26, 2019, 12:44 am
E' := ELLIPSE(THE_A(E), THE_A(E) + 1.0), E'' := ELLIPSE(THE_A(E') + 2.0, THE_B(E'));The expression coloured red violates the type constraint for ELLIPSE , so if E' is of type ELLIPSE, then it is impossible for it to acquire or stand for the (non-existent) value of that expression.
This is merely an arrangement of symbols, part of the expansion of shorthands in step a. It will never be executed, so it cannot fail a type constraint.
Thank you. So E' and E'' stand for text to be regarded as TD syntax. That's not the intent of RM Pre 21. TTM doesn't prescribe syntax. Saying that something in some D is equivalent to something expressed in TD doesn't require that D to be TD.
Hugh
Quote from dandl on November 27, 2019, 10:13 amQuote from Erwin on November 27, 2019, 8:20 amHe just assumes he is free to perform whatever "compiler magic" he is used to from other compilers doing it for other languages, and doesn't realise that apparently the intent of steps a.-d. is that if "rearranging terms" is not part of any of those steps, he is ***not*** free to perform that magic. I presume he knows what they say of assume.
I am satisfied that the operations I have proposed are of the same kind is those mentioned in TTM and the TD spec and achieve similar ends.
I've now resolved this question to my satisfaction, and I find that I've lost interest in persuading others to my point of view. Unless someone has something new to contribute, I think my work is done.
I'm not sure multiple claims of "compiler magic" count as work but if it's done, that's good. ;-)