Operation can be dispatching in only one type
in [ADA]
|
From: Dmitry A. Kazakov on 1 Dec 2009 06:12 On Tue, 1 Dec 2009 06:45:16 +0100, stefan-lucks(a)see-the.signature wrote: > On Tue, 1 Dec 2009, Dmitry A. Kazakov wrote: > >> On Mon, 30 Nov 2009 15:43:21 -0500, Robert A Duff wrote: > >>> Right. I think they should be equivalent. My solution is to use >>> two different symbols for (initial) assignment and (subsequent) >>> reassignment. >> >> But they cannot be, otherwise the semantics of ":=" would depend on the >> things done before: >> >> X : T; >> begin >> X := F (Y); -- Initialization > > No, at this point of time, X has been initialised to *some* value, even if > the value itself is undefined. So this is just a proper assignment. You should say that to Bob, because this is exactly my point. An object is *always* constructed <=> initialized before it can ever be used in any way (provided the language is typed <=> at any point of its existence any object has a definite type and only the operations defined for the type are available to the object). Initialization /= construction does not fit into this picture. >> X : T; >> begin >> X := Z; >> X := F (Y); -- [Re]assignment > > That is a proper assignment, as well. The only difference is that we > can be sure the before-assignment value of X is defined (assuming the > value of Z is a defined one). > > An initialisation would be > > X : T ::= F(Y); > begin > ... > > But you are right, Dmitry, nobody would not want to distinguish an > assignment to overwrite a potentially undefined value from an assignment > ovwerwriting a previously defined value. Of course I am! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: stefan-lucks on 1 Dec 2009 03:01 On Tue, 1 Dec 2009, Dmitry A. Kazakov wrote: > On Tue, 1 Dec 2009 06:45:16 +0100, stefan-lucks(a)see-the.signature wrote: > > > On Tue, 1 Dec 2009, Dmitry A. Kazakov wrote: > > > >> On Mon, 30 Nov 2009 15:43:21 -0500, Robert A Duff wrote: > > > >>> Right. I think they should be equivalent. My solution is to use > >>> two different symbols for (initial) assignment and (subsequent) > >>> reassignment. > >> > >> But they cannot be, otherwise the semantics of ":=" would depend on the > >> things done before: > >> > >> X : T; > >> begin > >> X := F (Y); -- Initialization > > > > No, at this point of time, X has been initialised to *some* value, even if > > the value itself is undefined. So this is just a proper assignment. > > You should say that to Bob, because this is exactly my point. No! You just moved to a different topic: [...] > Initialization /= construction does not fit into this picture. The issue was initialisation /= assignment (*) and the fact that in Ada both look syntactically the same. You seem to be the first to mention "construction" at all. BTW, I don't think initialisation and construction are actually identical, even though they have to be performed in close temporal proximity. If construction fails, this is a Storage_Error. A failed Initialisation is much more powerful -- it can raise any of your favourite exceptions. ;-) --------- Footnote: (*) I prefer to avoid the word "reassignment", which Bob would use. -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------
From: Georg Bauhaus on 1 Dec 2009 07:13 Robert A Duff schrieb: > stefan-lucks(a)see-the.signature writes: > >> On Sun, 22 Nov 2009, Robert A Duff wrote: >> >>> Ada uses the term "assignment" to refer to both "initial assignment / >>> initialization" and "assignment_statement / overwriting". >>> I'd prefer to use different symbols for the two. >>> We're not going to change Ada in that regard, for compatibility reasons, >>> but I'm thinking in my hobby language design to use the term "assignment" >>> for the initial one, and "reassignment" for the subsequent overwriting >>> one, and use different symbols for the two. >>> >>> So, for a limited type, "assignment" is legal, "reassignment" is not. >> Distinguishing the two different operations which are written as ":=" in >> Ada by using different words and even different symbols would make a lot of >> sense. > > I definitely want to use different symbols as well as different words. Am I correct in assuming that one important part of this argument is about referring to the value stored for some variable before this store has a "reasonable" value? (Where "reasonable" does not currently have a meaning that can be inferred from the LRM, I guess.) If so, and presuming the programming language Ada is very much, and explicitly, about storing and manipulating bits in registers, memory words, ... of digital computers in a strongly typed fashion: In this case I would know the use of being carried away by functional, uhm, phantasm, pardon the expression. Rather, why not have Ada turn warnings about "uninitialized" variables into a rule like Java's? Then we could rely on the language: compilers will detect uninitialized variables provided these do not have a pragma/keyword/... to say that uninitialized is what the programmer wants. Some fancy means to tell the compiler that this variable does indeed have a good first value like pragma Import. X : [constant] Car; -- default init, -- undefined, -- junk bits. Doesn't matter -- *no* pragma Import (Ada, X); begin Spare := X.Tire (5); -- would become illegal, -- as no value has been assigned yet. -- Currently, we get a warning if Fast then X := Ferrari.Make (...); else X := Fiat.Make (...); end if; Spare := X.Tire (5); Does the phrase "first value" make sense?
From: Georg Bauhaus on 1 Dec 2009 07:23 Georg Bauhaus schrieb: > In this case I would know the use of being carried away by functional, > uhm, phantasm, pardon the expression. There is a "not" after "would", sorry.
From: Georg Bauhaus on 1 Dec 2009 07:44
Georg Bauhaus schrieb: > Georg Bauhaus schrieb: > >> In this case I would know the use of being carried away by functional, >> uhm, phantasm, pardon the expression. > > There is a "not" after "would", sorry. It's missing in fact. I'll get something to eat... |