* Re: Software landmines (was: Why C++ is successful)
@ 1998-08-22 0:00 dewar
1998-08-23 0:00 ` Dale Stanbrough
1998-08-24 0:00 ` Richard D Riehle
0 siblings, 2 replies; 23+ messages in thread
From: dewar @ 1998-08-22 0:00 UTC (permalink / raw)
<<A 'return', at least in C/C++/VB, returns you to the place the current
procedure was called from. 'goto' control flow can be endlessly channeled
here and there and never has to return to where the initial linear control
flow was originally diverted. That seems to be a huge advantage of 'return'
over 'goto'.
>>
No, it is a huge advantage of return over a *bad* use of goto. But nearly
every feature in a language can be badly misused. We didn't eliminate
assignments from Ada, even though they can be (and are all the time)
horribly misused, and even though we know perfectly well that you can
write programs with no assignments with no loss in expressive power.
Instead we left in the assignment, and wise programmers use it to improve
the clarity of their programs, and foolish programmers create havoc with
it (by the way most programmers furiously overuse assignments, and it is
far too common to see a variable assignment used to establish a constant
value -- of course languages like traditional C which have no capability
for defining constants aggravate the problem!)
The goto is the same, wise programmers use it occasionally to clarify
their code, foolish programmers create havoc with it (although this happens
less often, since people are FAR more aware of the goto danger than the
assignment danger).
Fanatics in both cases decry straying from the pure road (yes there
are plenty of people who consider an assignment statement as just as
evil as a goto, and would not dream of using either :-)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-22 0:00 Software landmines (was: Why C++ is successful) dewar @ 1998-08-23 0:00 ` Dale Stanbrough 1998-08-23 0:00 ` dewar 1998-08-23 0:00 ` Andi Kleen 1998-08-24 0:00 ` Richard D Riehle 1 sibling, 2 replies; 23+ messages in thread From: Dale Stanbrough @ 1998-08-23 0:00 UTC (permalink / raw) dewar@gnat.com wrote: "No, it is a huge advantage of return over a *bad* use of goto. But nearly every feature in a language can be badly misused. We didn't eliminate assignments from Ada, even though they can be (and are all the time) horribly misused, and even though we know perfectly well that you can write programs with no assignments with no loss in expressive power." Do you have examples of the bad/excessive use of assignment statements? Dale ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-23 0:00 ` Dale Stanbrough @ 1998-08-23 0:00 ` dewar 1998-08-23 0:00 ` Andi Kleen 1 sibling, 0 replies; 23+ messages in thread From: dewar @ 1998-08-23 0:00 UTC (permalink / raw) In article <dale-2308981004320001@dale.ppp.cs.rmit.edu.au>, dale@cs.rmit.edu.au (Dale Stanbrough) wrote: > dewar@gnat.com wrote: > > "No, it is a huge advantage of return over a *bad* use of goto. But nearly > every feature in a language can be badly misused. We didn't eliminate > assignments from Ada, even though they can be (and are all the time) > horribly misused, and even though we know perfectly well that you can > write programs with no assignments with no loss in expressive power." > > Do you have examples of the bad/excessive use of assignment statements? > > Dale > Well of course there are many programmers, who in a manner analogous to the "gotophobes" consider *any* assignment statement as anathematic, and prefer languages where no assignments are allowed. It is of course common knowledge that assignment statements are unnecessary, and that just as it is possible to program without gotos, it is possible to program without assignment statements. Indeed it is a good excercise at least to make students learning Ada or some other reasonable language that has appropriate features, write a program avoiding assignment statements completely. But in normal use of a language like Ada, it certainly is relatively unlikely that many people would agree to this kind of extremism. It is actually probably the case that many Ada programmers would find the notion of programming without assignments as bizarre and foreign (in much the same way as a Fortran-67 programmer considers programming without gotos as bizarre, oops, that should be Fortran66). As for programs that overuse assignments these are indeed common. In fact it is rare that I see a big Ada program that does not have instances of initialized declarations of variables without a constant keyword that are in fact constants. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-23 0:00 ` Dale Stanbrough 1998-08-23 0:00 ` dewar @ 1998-08-23 0:00 ` Andi Kleen 1 sibling, 0 replies; 23+ messages in thread From: Andi Kleen @ 1998-08-23 0:00 UTC (permalink / raw) dale@cs.rmit.edu.au (Dale Stanbrough) writes: > dewar@gnat.com wrote: > > "No, it is a huge advantage of return over a *bad* use of goto. But nearly > every feature in a language can be badly misused. We didn't eliminate > assignments from Ada, even though they can be (and are all the time) > horribly misused, and even though we know perfectly well that you can > write programs with no assignments with no loss in expressive power." > > Do you have examples of the bad/excessive use of assignment statements? Assignments are equivalent to gotos. Just write the function as a big loop case .. statement, then you can use assignments as goto. In functional programming languages like ML or Scheme it is possible and easy to write assignless code, but these have lots of special tools (e.g. easy closures) that make that easier. -Andi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-22 0:00 Software landmines (was: Why C++ is successful) dewar 1998-08-23 0:00 ` Dale Stanbrough @ 1998-08-24 0:00 ` Richard D Riehle 1998-08-25 0:00 ` Andi Kleen ` (3 more replies) 1 sibling, 4 replies; 23+ messages in thread From: Richard D Riehle @ 1998-08-24 0:00 UTC (permalink / raw) In article <6rnhhe$e2u$1@nnrp1.dejanews.com>, dewar@gnat.com wrote: >... We didn't eliminate >assignments from Ada, even though they can be (and are all the time) >horribly misused, and even though we know perfectly well that you can >write programs with no assignments with no loss in expressive power. I cannot imagine writing a large program totally devoid of assignment statements. In fact, I sometimes see people programming around the assignment by parenthetical nesting of function returns and find it confusing, reminsicent of the German sentences of philosophers who, in an attempt to extract every nuance from an idea without leaving any possibility for misinterpretation, along with, what seems to be an attempt to avoid using an excessive number of periods in their sentences, construct long, dependent clause-filled sentences, the effect of which is to leave one, if, in fact, one is still reading, without any sense of what the original idea might have been from the beginning. Don't take away my assignment statements, Robert. The help me write crisp, short code sentences that ordinary mortals can understand. In fact, as an old time Fortranner, I sometimes write a function that looks like, function F ( ... ) return some-data-type is Result : some-data-type := initial-value; begin Result := algorithmic-part; return Result; end F; >... most programmers furiously overuse assignments, and it is >far too common to see a variable assignment used to establish a constant >value I am not sure what you mean. If I want to define constants, Zero : constant := 0; Null_List := some-value; how do I set the initial value without assignment. For private members in C++ this is really easy without assignment. I can use (must use) an initialization list. In Ada we have to have an assignment somewhere to make this happen. of course languages like traditional C which have no capability >for defining constants aggravate the problem!) But this is not true for C++ where one can use the initialization list as shown above and one can even define a function as a const, the parameters as const, etc. In this respect, C++ is a little more powerful (read, safer) than Ada especially when using pointers as parameters. For lots of other reasons, I still prefer Ada. Richard Riehle richard@adaworks.com www.adaworks.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Richard D Riehle @ 1998-08-25 0:00 ` Andi Kleen 1998-08-25 0:00 ` Brian Rogoff 1998-08-25 0:00 ` dennison ` (2 subsequent siblings) 3 siblings, 1 reply; 23+ messages in thread From: Andi Kleen @ 1998-08-25 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > > Don't take away my assignment statements, Robert. The help me write > crisp, short code sentences that ordinary mortals can understand. In > fact, as an old time Fortranner, I sometimes write a function that > looks like, > > function F ( ... ) return some-data-type is > Result : some-data-type := initial-value; > begin > Result := algorithmic-part; > return Result; > end F; I think you misunderstand. Even purely functional languages like ML have a way to write this so that you don't have to put the complete program into one expression. What they don't have, and I think that is what Robert was refering to, is a way to cause side effects and change the program state by an assignment. -Andi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-25 0:00 ` Andi Kleen @ 1998-08-25 0:00 ` Brian Rogoff 0 siblings, 0 replies; 23+ messages in thread From: Brian Rogoff @ 1998-08-25 0:00 UTC (permalink / raw) On 25 Aug 1998, Andi Kleen wrote: > Richard D Riehle <laoXhai@ix.netcom.com> writes: > > > > Don't take away my assignment statements, Robert. The help me write > > crisp, short code sentences that ordinary mortals can understand. In > > fact, as an old time Fortranner, I sometimes write a function that > > looks like, > > > > function F ( ... ) return some-data-type is > > Result : some-data-type := initial-value; > > begin > > Result := algorithmic-part; > > return Result; > > end F; > > I think you misunderstand. Even purely functional languages like ML have I think ML is what most FPers would call impure, since the MLs that I know of, SML and CAML, both have assignable references. ML is "functional" in that it has higher-order functions, but the designers of ML consciously included assignment. If you look closely, you can see a little bit of ML in Ada-95. -- Brian ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Richard D Riehle 1998-08-25 0:00 ` Andi Kleen @ 1998-08-25 0:00 ` dennison 1998-08-28 0:00 ` Matthew Heaney [not found] ` <35eca5d9.4354839@news.geccs.gecm.com> 3 siblings, 0 replies; 23+ messages in thread From: dennison @ 1998-08-25 0:00 UTC (permalink / raw) In article <6rsg0d$pcj@dfw-ixnews3.ix.netcom.com>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > statements. In fact, I sometimes see people programming around the > assignment by parenthetical nesting of function returns and find it > confusing, reminsicent of the German sentences of philosophers who, > in an attempt to extract every nuance from an idea without leaving any > possibility for misinterpretation, along with, what seems to be an > attempt to avoid using an excessive number of periods in their sentences, > construct long, dependent clause-filled sentences, the effect of which > is to leave one, if, in fact, one is still reading, without any sense > of what the original idea might have been from the beginning. Wow. You even write self-documenting prose. :-) -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Richard D Riehle 1998-08-25 0:00 ` Andi Kleen 1998-08-25 0:00 ` dennison @ 1998-08-28 0:00 ` Matthew Heaney 1998-08-28 0:00 ` Richard D Riehle [not found] ` <35eca5d9.4354839@news.geccs.gecm.com> 3 siblings, 1 reply; 23+ messages in thread From: Matthew Heaney @ 1998-08-28 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > >... most programmers furiously overuse assignments, and it is > >far too common to see a variable assignment used to establish a constant > >value > > I am not sure what you mean. If I want to define constants, > > Zero : constant := 0; > Null_List := some-value; > > how do I set the initial value without assignment. For private > members in C++ this is really easy without assignment. I can use > (must use) an initialization list. In Ada we have to have an > assignment somewhere to make this happen. The issue lies in the difference between "assignment" and "binding." The problem with Ada is that the syntax for both is the same, so whenever people see ":=" they always think of assignment, even when it really means binding. In the example above, Zero : constant := 0; is a binding operation, not an assignment operation. The name Zero is bound to a value. Indeed, any time you see the keyword "constant" in a declaration, then you should treat that to mean "bind," not "assign." Ada is wildly inconsistent wrt binding. To bind a name to a function, I use the keyword "is": function F (X : T1) return T2 is begin <body> end F; means the same thing as type FT is function (X : T1) return T2; F : constant FT := begin <body> end; Why not use the operator "is" everywhere binding is intended? I think it's true that in Eiffel, binding doesn't use the assignment operator, it uses the keyword "is", as in Zero : Integer is 0; which is the equivalent of Zero : constant Integer := 0; in Ada. So when Robert says "programmers misuse assignment," he means (I think) that they are using assignment when they really want to use binding. The latter use is indicating by the presence of the keyword "constant". Unfortunately, the syntax for binding in Ada also uses the assignment operator, so Ada programmers blur the distinction between binding and assignment (if they are aware of it at all). I regard this as a flaw in the language. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` Matthew Heaney @ 1998-08-28 0:00 ` Richard D Riehle 1998-08-29 0:00 ` Matthew Heaney 1998-08-29 0:00 ` Matthew Heaney 0 siblings, 2 replies; 23+ messages in thread From: Richard D Riehle @ 1998-08-28 0:00 UTC (permalink / raw) In article <m3g1eithld.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: In response to Richard Riehle's question about initialization of values with the assignment statement, > >The issue lies in the difference between "assignment" and "binding." I ran to my bookshelf to find an entry in any computer science text on "binding" in the context you have used it. None. Reference, please. >The problem with Ada is that the syntax for both is the same, so >whenever people see ":=" they always think of assignment, even when it >really means binding. I understand the distinction, and your reference to Eiffel, below, is correct. >In the example above, > Zero : constant := 0; >is a binding operation, not an assignment operation. The name Zero is >bound to a value. So, in this respect, C++ initialization lists better express the "binding" requirement than Ada assignments. >Indeed, any time you see the keyword "constant" in a declaration, then >you should treat that to mean "bind," not "assign." >Ada is wildly inconsistent wrt binding. To bind a name to a function, I >use the keyword "is": > >function F (X : T1) return T2 is >begin > <body> >end F; > >means the same thing as > >type FT is function (X : T1) return T2; > >F : constant FT := begin <body> end; > >Why not use the operator "is" everywhere binding is intended? Your function example is interesting. In an Eiffel feature declaration, the syntatical placement for "is" in declaring a function is the same as Ada rather than as you prefer. >I think it's true that in Eiffel, binding doesn't use the assignment >operator, it uses the keyword "is", as in > > Zero : Integer is 0; > This is true. A feature declaration in Eiffel is the same for any declaration. This is called by Bertrand, "the principle of minimum surprise." When referencing any feature in an Eiffel class, the client of the class sees attributes identically to functions. An "is" is used only for constant or routine feature. Non-constant attributes are not initialized with a "is" keyword. Also, the Eiffel model for "attachment" and "reattachment" more closely approximates what you and Robert are describing as alternatives to excessive use of the assignment statement. With that understanding in place, I suggest that, in using the assignment operation for defining constants, the difference between "binding" and "assignment" is a rather subtle semantic issue for most practical programmers. Also, several consecutive assignment statements in Ada will often be more readable than the parentheticaly clauses of function returns that serve as their substitute. Ada, unlike Eiffel, is not designed to reduce the number of assignment statements. The suggestion that we use fewer assignment statements is liable to create the same mess that "gotoless" programming fomented in the COBOL world. Robert knows that pre-ANSI 85 COBOL was inadequately designed to support programs without GO TO statements. Only with the advent of "END ..." constructs did COBOL become more amenable to reducing the number of GO TO's. Ada is designed to encourage the use of the assigment statement. Suggesting that we do not use it so often is probably counterproductive and can only be realized with some important changes in the language. You have already noted some of these, Matthew. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` Richard D Riehle @ 1998-08-29 0:00 ` Matthew Heaney 1998-08-29 0:00 ` Matthew Heaney 1 sibling, 0 replies; 23+ messages in thread From: Matthew Heaney @ 1998-08-29 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > >The issue lies in the difference between "assignment" and "binding." > > I ran to my bookshelf to find an entry in any computer science text > on "binding" in the context you have used it. None. Reference, please. Here are some references: Programming Language Concepts and Paradigms David A. Watt Programming Languages: Design and Implementation Terrence W. Pratt and Marvin V. Zelkowitz Principles of Programming Languages R.D. Tennent Programming Language Structures Carlo Ghezzi and Mehdi Jazayeri Although they're a bit heavy on the theory, you might also want to take a look at: Introduction to the Theory of Programming Languages Bertrand Meyer The Denotational Description of Programming Languages Michael Gordon The Meyer book contains a good description of the meaning of assignment. Hope that helps, Matt ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` Richard D Riehle 1998-08-29 0:00 ` Matthew Heaney @ 1998-08-29 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1 sibling, 1 reply; 23+ messages in thread From: Matthew Heaney @ 1998-08-29 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > So, in this respect, C++ initialization lists better express the > "binding" requirement than Ada assignments. One of the areas in Ada in which the assignment vs initialization issue arises is in the declaration of limited types: declare O : LT; begin Initialize (O); <use O> The thing I find distasteful here is that the initialization of object O occurs after its declaration. Sometimes this means the state of O is undefined. (However, many times limited objects come with a defined, default state. For example, Is_Open is defined to return False for a newly declared instance of File_Type.) I've advocated in the past that the language syntax should be amended to add an initialization operation ("constructor"): declare File : File_Type'Open (In_Mode, "matt.dat"); begin We could even use the constant keyword in such a declaration. > Also, several consecutive assignment statements in Ada will often be > more readable than the parentheticaly clauses of function returns that > serve as their substitute. Agree. I often see programmers use many nested function calls in an expression. What I have to do then is to mentally unravel the expression. So why not save me the trouble? Use a declare block to declare a few intermediate objects, and feed them to the ultimate subprogram call. > The suggestion that we use fewer assignment statements is liable to > create the same mess that "gotoless" programming fomented in the COBOL > world. Let's make sure everyone knows what this means: o It DOES mean "don't use a variable when a constant will do." o It does NOT mean "use nested function calls to return intermediate values, instead of declaring intermediate constant objects" Yes, you really should use constant object declarations to hold intermediate values, even though this requires a few more "assignments." (The scare quotes are there to remind the reader that the declaration of a constant object isn't really an assignment.) > Ada is designed to encourage the use of the assigment statement. Yes. Far too few programmers use declare blocks and constant object declarations to simplify complex expressions. Instead of Op (Get_A (10), Get_B (X), Get_C (Y)); it's better to do declare A : constant Integer := Get_A (10); B : constant Float := Get_B (X); C : constant Boolean := Get_C (Y); begin Op (A, B, C); end; As we have noted, the declarations above aren't really "assignment" statements. They are "binding" operations. The distinction would be more clear (and consistent) if the language allowed you to say: declare A : Integer is Get_A (10); B : Float is Get_B (X); C : Boolean is Get_C (Y); begin Op (A, B, C); end; The "renames" clause is a binding operator in Ada (although technically it binds a name to an object, not a value). A hip way to do the above directly in the language is declare A : Integer renames Get_A (10); B : Float renames Get_B (X); C : Boolean renames Get_C (Y); begin Op (A, B, C); end; That way we can avoid the use of the assignment operator, so the declaration won't be confused with an assignment statement. It's a bit of a bummer that we have 3 ways ("constant T :=", "renames", "is") of doing essentially the same thing. Why not just one way? > Suggesting that we do not use it so often is probably > counterproductive and can only be realized with some important changes > in the language. An unambiguous way to say this is that, in a declaration, you should use the keyword "constant" whenever the object doesn't change its value. Yet another way to say this is "don't use assignment when you really mean binding." Matt P.S. About the meaning of binding: let me dig up my books on programming language theory. You usually see it mentioned in books about functional programming, and in explications of denotational semantics. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-29 0:00 ` Matthew Heaney @ 1998-09-06 0:00 ` John G. Volan 1998-09-07 0:00 ` Mats Weber 0 siblings, 1 reply; 23+ messages in thread From: John G. Volan @ 1998-09-06 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > Yes. Far too few programmers use declare blocks and constant object > declarations to simplify complex expressions. Instead of > > Op (Get_A (10), Get_B (X), Get_C (Y)); > > it's better to do > > declare > A : constant Integer := Get_A (10); > B : constant Float := Get_B (X); > C : constant Boolean := Get_C (Y); > begin > Op (A, B, C); > end; There's a subtle difference between these two examples: In the latter case, the local constant declarations will be elaborated in the indicated order, so the function calls are going to be done sequentially. But in the former case, the language defines no particular order of evaluation of the actual procedure parameters, so these function calls might occur in any order. A smart compiler for the right kind of target machine may even be able to schedule these calls to occur in parallel. ... > The "renames" clause is a binding operator in Ada (although technically > it binds a name to an object, not a value). A hip way to do the above > directly in the language is > > declare > A : Integer renames Get_A (10); > B : Float renames Get_B (X); > C : Boolean renames Get_C (Y); > begin > Op (A, B, C); > end; I'm curious: Does this have the same effect as the above, i.e., are the function calls forced into a sequential order? Or is their evaluation deferred until the aliases A, B, and C are actually used as parameters to the Op call, in which case the aliased function calls get executed in an undefined order? -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-06 0:00 ` John G. Volan @ 1998-09-07 0:00 ` Mats Weber 1998-09-07 0:00 ` dewarr 0 siblings, 1 reply; 23+ messages in thread From: Mats Weber @ 1998-09-07 0:00 UTC (permalink / raw) John G. Volan wrote: > > declare > > A : Integer renames Get_A (10); > > B : Float renames Get_B (X); > > C : Boolean renames Get_C (Y); > > begin > > Op (A, B, C); > > end; > > I'm curious: Does this have the same effect as the above, i.e., are the > function calls forced into a sequential order? Or is their evaluation > deferred until the aliases A, B, and C are actually used as parameters > to the Op call, in which case the aliased function calls get executed in > an undefined order? Yes, it has the same effect. Each function call is evaluated during the elaboration of the renames it appears in. You are in fact renaming the object that contains the function result. (See RM 3.3(10)). ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-07 0:00 ` Mats Weber @ 1998-09-07 0:00 ` dewarr 1998-09-08 0:00 ` Tucker Taft 1998-09-16 0:00 ` Software landmines (was: Why C++ is successful) Matthew Heaney 0 siblings, 2 replies; 23+ messages in thread From: dewarr @ 1998-09-07 0:00 UTC (permalink / raw) In article <35F3FF42.D1E163E0@elca-matrix.ch>, Mats.Weber@elca-matrix.ch wrote: > John G. Volan wrote: > > > > declare > > > A : Integer renames Get_A (10); > > > B : Float renames Get_B (X); > > > C : Boolean renames Get_C (Y); > > > begin > > > Op (A, B, C); > > > end; > > > > I'm curious: Does this have the same effect as the above, i.e., are the > > function calls forced into a sequential order? Or is their evaluation > > deferred until the aliases A, B, and C are actually used as parameters > > to the Op call, in which case the aliased function calls get executed in > > an undefined order? > > Yes, it has the same effect. Each function call is evaluated during the > elaboration of the renames it appears in. You are in fact renaming the object > that contains the function result. (See RM 3.3(10)). > I must say that I find the renaming of function calls like this to be a confusing oddity. It seems much clearer to me to use ordinary constant declarations. The two seem completely equivalent! -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-07 0:00 ` dewarr @ 1998-09-08 0:00 ` Tucker Taft 1998-09-08 0:00 ` Precalculation of parameters (was: Software landmines) dennison 1998-09-16 0:00 ` Software landmines (was: Why C++ is successful) Matthew Heaney 1 sibling, 1 reply; 23+ messages in thread From: Tucker Taft @ 1998-09-08 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote: : In article <35F3FF42.D1E163E0@elca-matrix.ch>, : Mats.Weber@elca-matrix.ch wrote: : > John G. Volan wrote: : > : > > > declare : > > > A : Integer renames Get_A (10); : > > > B : Float renames Get_B (X); : > > > C : Boolean renames Get_C (Y); : > > > begin : > > > Op (A, B, C); : > > > end; : > > : > > I'm curious: Does this have the same effect as the above, i.e., are the : > > function calls forced into a sequential order? Or is their evaluation : > > deferred until the aliases A, B, and C are actually used as parameters : > > to the Op call, in which case the aliased function calls get executed in : > > an undefined order? : > : > Yes, it has the same effect. Each function call is evaluated during the : > elaboration of the renames it appears in. You are in fact renaming the object : > that contains the function result. (See RM 3.3(10)). : > : I must say that I find the renaming of function calls : like this to be a confusing oddity. It seems much clearer : to me to use ordinary constant declarations. The two : seem completely equivalent! They are equivalent unless the result type is return-by-reference. If the result-type is return-by-reference, only the rename would be legal, and simply denotes the same object denoted by the original return statement's expression. If the result-type is the more common return-by-reference, then the two are equivalent for all intents and purposes, though you might think that the renaming approach could result in fewer copies in some (not-too-smart ;-) compilers. By the way, the original point that a "smart" compiler can parallelize: Op(Get_A(..), Get_B(..), Get_C(..)) more easily than the "sequential" form involving named constants is a bit bogus. To parallelize, the compiler needs to prove that Get_A, Get_B, and Get_C don't interfere with one another. Given that, there is no reason that the "sequential" form couldn't be parallelized as well. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ^ permalink raw reply [flat|nested] 23+ messages in thread
* Precalculation of parameters (was: Software landmines) 1998-09-08 0:00 ` Tucker Taft @ 1998-09-08 0:00 ` dennison 1998-09-09 0:00 ` Tucker Taft 0 siblings, 1 reply; 23+ messages in thread From: dennison @ 1998-09-08 0:00 UTC (permalink / raw) In article <Eyz7Co.J4t.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > By the way, the original point that a "smart" compiler can parallelize: > > Op(Get_A(..), Get_B(..), Get_C(..)) > > more easily than the "sequential" form involving named constants is a > bit bogus. To parallelize, the compiler needs to prove that Get_A, > Get_B, and Get_C don't interfere with one another. Given that, there > is no reason that the "sequential" form couldn't be parallelized as well. But if the language specifically states that the order of evaluation of parameters is undefined, then it doesn't have to prove they don't interfere. It can just assume they shouldn't. I don't know if that's the way Ada is defined, but I believe that was the claim that was being made. Is that actually the rule? -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Precalculation of parameters (was: Software landmines) 1998-09-08 0:00 ` Precalculation of parameters (was: Software landmines) dennison @ 1998-09-09 0:00 ` Tucker Taft 1998-09-09 0:00 ` dennison 0 siblings, 1 reply; 23+ messages in thread From: Tucker Taft @ 1998-09-09 0:00 UTC (permalink / raw) dennison@telepath.com wrote: : In article <Eyz7Co.J4t.0.-s@inmet.camb.inmet.com>, : stt@houdini.camb.inmet.com (Tucker Taft) wrote: : > By the way, the original point that a "smart" compiler can parallelize: : > : > Op(Get_A(..), Get_B(..), Get_C(..)) : > : > more easily than the "sequential" form involving named constants is a : > bit bogus. To parallelize, the compiler needs to prove that Get_A, : > Get_B, and Get_C don't interfere with one another. Given that, there : > is no reason that the "sequential" form couldn't be parallelized as well. : But if the language specifically states that the order of evaluation of : parameters is undefined, then it doesn't have to prove they don't interfere. : It can just assume they shouldn't. Running two computations in parallel is very different from running them in an "arbitrary" (but still sequential) order. Suppose each function adds one to the global variable "Count". You get the same result independent of which order the functions are evaluated, but you don't get the same result if you run them in parallel, and the machine instructions involved in adding one to the global are interleaved arbitrarily. : ... I don't know if that's the way Ada is : defined, but I believe that was the claim that was being made. : Is that actually the rule? RM95 6.4(10) permits evaluation of parameters in an "arbitrary" order. RM95 1.1.4(18) defines "arbitrary" order, indicating that it must be an order that is equivalent to some sequential ordering. If you have the annotated RM, it explicitly mentions the example given above in AARM 1.1.4(18.d). : -- : T.E.D. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Precalculation of parameters (was: Software landmines) 1998-09-09 0:00 ` Tucker Taft @ 1998-09-09 0:00 ` dennison 1998-09-10 0:00 ` Tucker Taft 0 siblings, 1 reply; 23+ messages in thread From: dennison @ 1998-09-09 0:00 UTC (permalink / raw) In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > dennison@telepath.com wrote: > > : Is that actually the rule? > > RM95 6.4(10) permits evaluation of parameters in an "arbitrary" > order. RM95 1.1.4(18) defines "arbitrary" order, indicating > that it must be an order that is equivalent to some sequential > ordering. ^^^^^^^^^^^^^^^ ^^^^^^^^ Ahhh. That was the part I was missing. So language was specifically added to the RM to prevent compilers from blindly parallelizing this. Out of curiosity, what was the reason this was done? I can't find anything about it in the Rationale. -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Precalculation of parameters (was: Software landmines) 1998-09-09 0:00 ` dennison @ 1998-09-10 0:00 ` Tucker Taft 1998-09-10 0:00 ` dewarr 0 siblings, 1 reply; 23+ messages in thread From: Tucker Taft @ 1998-09-10 0:00 UTC (permalink / raw) dennison@telepath.com wrote: : In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>, : stt@houdini.camb.inmet.com (Tucker Taft) wrote: : > dennison@telepath.com wrote: : > : > : Is that actually the rule? : > : > RM95 6.4(10) permits evaluation of parameters in an "arbitrary" : > order. RM95 1.1.4(18) defines "arbitrary" order, indicating : > that it must be an order that is equivalent to some sequential : > ordering. ^^^^^^^^^^^^^^^ : ^^^^^^^^ : Ahhh. That was the part I was missing. So language was specifically added to : the RM to prevent compilers from blindly parallelizing this. Out of : curiosity, what was the reason this was done? I can't find anything about it : in the Rationale. All code within a single task is defined to be "sequential." This is critical to being able to prove things about safe access to global variables. If the RM allowed parallel evaluation of parameter expressions, all of the discussion in RM95 9.10 about sharing variables between tasks and about "independent addressability" would have to apply to sharing variables and manipulating neighboring packed-array components between different parameter evaluations, which would dramatically increase the likelihood of erroneous execution per 9.10(11). See RM95 9.10 for a discussion of these issues. The critical paragraph is 9.10(13), where any two actions that occur as part of the execution of a single task are defined to be "sequential." In some ways, that *is* the definition of a "task." : -- : T.E.D. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Precalculation of parameters (was: Software landmines) 1998-09-10 0:00 ` Tucker Taft @ 1998-09-10 0:00 ` dewarr 0 siblings, 0 replies; 23+ messages in thread From: dewarr @ 1998-09-10 0:00 UTC (permalink / raw) In article <Ez28B6.DMI.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > dennison@telepath.com wrote: > > : In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>, > : stt@houdini.camb.inmet.com (Tucker Taft) wrote: > : > dennison@telepath.com wrote: > : > > : > : Is that actually the rule? > : > > : > RM95 6.4(10) permits evaluation of parameters in an "arbitrary" > : > order. RM95 1.1.4(18) defines "arbitrary" order, indicating > : > that it must be an order that is equivalent to some sequential > : > ordering. ^^^^^^^^^^^^^^^ > : ^^^^^^^^ > > : Ahhh. That was the part I was missing. So language was specifically added to > : the RM to prevent compilers from blindly parallelizing this. Out of > : curiosity, what was the reason this was done? I can't find anything about it > : in the Rationale. > > All code within a single task is defined to be "sequential." This > is critical to being able to prove things about safe access to global > variables. If the RM allowed parallel evaluation of parameter expressions, > all of the discussion in RM95 9.10 about sharing variables between tasks and > about "independent addressability" would have to apply to sharing variables > and manipulating neighboring packed-array components between different > parameter evaluations, which would dramatically increase the likelihood > of erroneous execution per 9.10(11). > > See RM95 9.10 for a discussion of these issues. The critical paragraph > is 9.10(13), where any two actions that occur as part of the execution > of a single task are defined to be "sequential." In some ways, that > *is* the definition of a "task." > > : -- > : T.E.D. > > -- > -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ > Intermetrics, Inc. Burlington, MA USA > Note that in one respect Ada went MUCH too far, and that is the decision that for a binary operator you must evaluate either left-then-right, or right-then-left. While I don't think anyone would argue for the collateral (parallel) evaluation semantics of Algol-68 in a language with side effects, it is still annoying that in (f + g) + (h + i) where f,g,h,i are function calls, that f/g/h/i g/f/h/i f/g/i/h g/f/i/h h/i/f/g h/i/g/f i/h/f/g i/h/g/f are all permitted orders, but no other orders (e.g. f/h/g/i are permissible. This seems to me to be silly over specification. Note that it is very hard to construct an example where this matters (and even the ACVC tests do not test for this). -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-07 0:00 ` dewarr 1998-09-08 0:00 ` Tucker Taft @ 1998-09-16 0:00 ` Matthew Heaney 1 sibling, 0 replies; 23+ messages in thread From: Matthew Heaney @ 1998-09-16 0:00 UTC (permalink / raw) dewarr@my-dejanews.com writes: > > > > declare > > > > A : Integer renames Get_A (10); > > > > B : Float renames Get_B (X); > > > > C : Boolean renames Get_C (Y); > > > > begin > > > > Op (A, B, C); > > > > end; > I must say that I find the renaming of function calls > like this to be a confusing oddity. It seems much clearer > to me to use ordinary constant declarations. The two > seem completely equivalent! Funny, since using Ada95, I always use "renames" in preference to "constant T :=". One difference is that renames is available for limited types: declare File : File_Type renames Standard_Output; begin This nicely emphasizes that this isn't assignment: it's a binding of a name to an object, which is completely different, and justifies the different syntax. For a while now I've felt that Ada really got the concept of initialization all wrong. Dijkstra speaks to the issue in Chap 10, An Essay on the Notion: "The Scope of Variables" in his book A Displine of Programming: (start of quote) Upon second thought it seems only honest to use different notations [for initialization and assignment], for they are very different operations: while the initializing statement is in a sense a creative one (it creates a variable with an initial value), the true assignment statement is a destructive one in the sense that it destroys information, viz. the variable's former value. (end of quote) He hit the nail right on the head. The problem with Ada is that it blurs the distinction between initialization and assignment, especially since it uses the assignment operator in a constant declaration. (Although even Dijkstra used the assignment operator in his declarations. The only difference is that he marks initialization with the keyword "vir" (for "virgin"), and Ada marks it using "constant".) Robert, you pointed out in an earlier post how many programmers "misuse assignment." This is confirmed by my own experience. However, if many programmers do the wrong thing wrt a specific language construct, then that may indicate something is wrong with the language itself, and not with the programmers. The use of the assignment operator where initialization is intended tends to inculcate the idea that there really isn't any difference. This is unfortunate. One obvious problem with the Ada approach is that limited objects can't be initialized during their declaration (except for default initialization, of course). Better would have been true constructor operations, with a different syntax. In the past I've suggested something like: declare File : File_Type'Open ("matt.dat", In_File); begin so that no assignment operator is required in order to do initialization. Unfortunately, not being able to initialize a limited object during its elaboration means that there's a zone between the object declaration and object initialization, in which the state of the object may be undefined. (Or only defined via what's possible using default initialization - but that kind of initialization isn't very interesting or useful.) It also means if I build up a value in a declarative region, via a series of constant declarations, then when I reach the declaration of a limited object, I have to stop the declarative region, since I can't use the limited object until I've initialized it, which doesn't occur until the start of the exectuble region. This is a real bummer, since I have to create variables when constants would do. The assignment operator in Ada is very confusing still, because I can use it as a renames operator for a limited object that's a default parameter: procedure Op (File : File_Type := Standard_Output); Very confusing indeed, since the assignment operator is clearly not being used for assignment! I'm all for language parsimony, but this overloading of the assignment operator is only going to confuse neophytes. So if I seem inclined to use a renames clause when the language allows me to use assignment operator, it's because I'm trying to emphasize that the declaration has the sense of a binding operation, and to de-emphasize any notion of assignment. When I look at the constant declaration declare A : constant Integer := Get_A (...); begin I really have to cringe, since it looks so much like an assignment. Thinking about it more, I think that Ada unnecessarily exposed the fact that an entity is a constant object, when all a client really cares about is that it's a name bound to a value. It would have been hipper if the language allowed this to be hidden somehow, so that only the implementator of an abstraction has to know that the return value is really a constant object. It would also be more consistent with other syntactic constructs that bind a name to a value: package P is ... binds the name P to a package. procedure Op (...) is ... binds the name Op to a procedure. type T is ... bind the name T to a type. -but- declare A : constant Integer := ...; begin binds the name A to a value??? Why not a uniform syntax: declare A : Integer is ...; begin or maybe declare value A : Integer is ...; Using renames comes close to being able to do that: declare A : Integer renames ...; begin It's sort of a bummer that we have two different keywords (renames vs is) to do binding. But the language problem we really need to solve is array initialization. For example, it's sometimes required to have array components whose state is a function of their index value. If the array components are limited, then there's no simple way to do that (say, to pass in the index value as the discriminant of a task object, to serve as its Id), except by using two array declarations and indirection. One idea I had is something like: task type Task_Type (Id : Positive) is ...; type Array_Type is array (Positive range <>) of Task_Type; declare O : Array_Type (1 .. N)'(for I in O'Range O(I)); begin You could even invoke a constructor using this syntax: type CT is ...; constructor CT'Initialize (Index : Positive); type T is array (Positive range <>) of CT; declare O : T (1 .. N)'(for I in O'Range O(I)'Initialize (I)); begin ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <35eca5d9.4354839@news.geccs.gecm.com>]
* Re: Software landmines (was: Why C++ is successful) [not found] ` <35eca5d9.4354839@news.geccs.gecm.com> @ 1998-09-01 0:00 ` Richard D Riehle 0 siblings, 0 replies; 23+ messages in thread From: Richard D Riehle @ 1998-09-01 0:00 UTC (permalink / raw) Brian, Silly indeed! I do not appreciate your use of the pejorative "silly" in response to my postingsince it seems to be a deliberate insult. I do admit that my hastily composed example could have been coded with more clarity. It did not occur to me that I would need to submit a perfect code example to make such a simple point but, since martinets abound, I submit a new, probably unnecessary, example. In case you have missed my original point in your zeal to criticize the code fragment, it is as follows: Ada is designed to encourage use of the assignment statement if we also want our code to be clear and readable. This was in response to Robert's (correct) assertion that programmers use assignment statements too liberally. I am appending your code example and mine in case some masochist wants to read it. I hope you understand that my example was not intended to represent real code. Perhaps the way I wrote the assignment statement confused you regarding my intentions. I concur that, if there is a simple algorithm, it can be stated as part of the declaration. In the kind of function I had in mind, there could be multiple possible values for the Result. In this case, the choice is between, Example (1) function F1 (paramter-list) return Result-type is Result : Result-type := initial-value; begin if condition-1 then Result := result-1; elsif condition-2 then Result := result-2; else Result := result-3; end if; return Result; end F1; versus Example(2) function F2 (paramter-list) return Result-type is begin if condition-1 then return result-1; elsif condition-2 then return result-2; else return result-3; end if; return Result; end F2; The two (simplified) functions epitomize the debate about a particular coding style. Example(2) illustrates how functions avoid using an extraneous assignment statement. Some practitioners prefer Example(1). I use both in my coding. It depends on the complexity of the function, my audience (everyone on the project is an ex-Fortranner), along with several helpings of intuition. Over the years I have found that Example(1) has been less error-prone and easier for the average programmer to maintain. Your mileage may vary according your experience. -- ==================== Original Postings ==================== -- What follows is my original message along with Mr. Orpin's -- rather impolite reply. -- =========================================================== In article <35eca5d9.4354839@news.geccs.gecm.com>, abuse@borpin.demon.co.uk (Brian Orpin) wrote: in response to the following code fragment submitted by me, >On Mon, 24 Aug 1998 19:47:31 GMT, Richard D Riehle ><laoXhai@ix.netcom.com> wrote: > >> Don't take away my assignment statements, Robert. The help me write >> crisp, short code sentences that ordinary mortals can understand. In >> fact, as an old time Fortranner, I sometimes write a function that >> looks like, > >> function F ( ... ) return some-data-type is >> Result : some-data-type := initial-value; >> begin >> Result := algorithmic-part; >> return Result; >> end F; > >Which of course is pretty silly <g>. Result has a default value that is >never used. Could easily be written.. > >function F ( ... ) return some-data-type is > Result : some-data-type := algorithmic-part; >begin > return Result; >end F; > >or even > >function F ( ... ) return some-data-type is >begin > return algorithmic-part; >end F; > >YMMV ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~1998-09-16 0:00 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-08-22 0:00 Software landmines (was: Why C++ is successful) dewar 1998-08-23 0:00 ` Dale Stanbrough 1998-08-23 0:00 ` dewar 1998-08-23 0:00 ` Andi Kleen 1998-08-24 0:00 ` Richard D Riehle 1998-08-25 0:00 ` Andi Kleen 1998-08-25 0:00 ` Brian Rogoff 1998-08-25 0:00 ` dennison 1998-08-28 0:00 ` Matthew Heaney 1998-08-28 0:00 ` Richard D Riehle 1998-08-29 0:00 ` Matthew Heaney 1998-08-29 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1998-09-07 0:00 ` Mats Weber 1998-09-07 0:00 ` dewarr 1998-09-08 0:00 ` Tucker Taft 1998-09-08 0:00 ` Precalculation of parameters (was: Software landmines) dennison 1998-09-09 0:00 ` Tucker Taft 1998-09-09 0:00 ` dennison 1998-09-10 0:00 ` Tucker Taft 1998-09-10 0:00 ` dewarr 1998-09-16 0:00 ` Software landmines (was: Why C++ is successful) Matthew Heaney [not found] ` <35eca5d9.4354839@news.geccs.gecm.com> 1998-09-01 0:00 ` Richard D Riehle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox