phil@uxg.cso.uiuc.edu (12/21/88)
How did the := come into being in languages like Algol, Pascal, and Ada? I still prefer the way it is in C (and a little lesser so in Rexx and Fortran). My second beef against := is the extra character. My FIRST beef against := is the KeYbOaRd ShIfTiNg I hAvE tO kEeP dOiNg FoR iT.
rbk@hpctdls.HP.COM (Richard Katz) (12/23/88)
>/ hpctdls:comp.lang.misc / phil@uxg.cso.uiuc.edu / 2:36 pm Dec 20, 1988 / >How did the := come into being in languages like Algol, Pascal, and Ada? >I still prefer the way it is in C (and a little lesser so in Rexx and >Fortran). My second beef against := is the extra character. My FIRST >beef against := is the KeYbOaRd ShIfTiNg I hAvE tO kEeP dOiNg FoR iT. ---------- I don't know how the := came into being, but I don't have any beef about it. In fact, I think Pascal use of it is good. Pascal uses = as a boolean operator and := as asignment. First, := seems better since i = i + 1 looks real funny. Also, a nice feature is that 'if ( i := 10 )' will produce a syntax error in Pascal while 'if ( i = 10 )' will produce an assignment in C, usually not intended. FORTRAN uses .EQ. to make sure that there is no mixup between the assignment operator and the comparison operator. Perhaps i <- 10 would make more sense than := although it is slightly more awkward to type. Typing the extra character is not that hard and more than pays for itself by eliminating the occasional typo in Boolean expressions. rich katz hewlett packard p o box 7050 colorado springs, co 80933-7050 email: rbk@hpctdlb.hp.com
eric@snark.UUCP (Eric S. Raymond) (12/23/88)
In article <3300001@uxg.cso.uiuc.edu>, phil@uxg.cso.uiuc.edu writes: > How did the := come into being in languages like Algol, Pascal, and Ada? It originated with ALGOL-60. The European `bondage-and-discipline' school of language design (the people who brought you Algol-68, Pascal, Modula, Ada, and Modula-2 and are now having yet another try at getting their mistakes right in Modula-3) likes to claim apostolic descent from that language, and they've retained := and some of its other crotchets. -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
new@udel.EDU (Darren New) (12/23/88)
I understand that the := was an attempt to draw a left-arrow on a card punch. Nowadays, it would be <-, but having no less-than sign, := was chosen. I could dig up the reference if anyone cares. - Darren
smryan@garth.UUCP (Xxxxxx Xxxx) (12/23/88)
>How did the := come into being in languages like Algol, Pascal, and Ada? IAL 58. >I still prefer the way it is in C (and a little lesser so in Rexx and Booooo! Hisssss! It's all in how you read it. I read `a:=b' as `a becomes b' not `a equals b.' `a equals b' is `a=b.' So what about the shift-key? We're all touch-typists, rught? -- As Loki walked with Othin wise, -- s m ryan with Hoenir under summer skies, they found a river swift and deep. -- Andwari's Gem They followed whither waters leap. -- 1/2
dana@gmu90x.UUCP (J Dana Eckart) (12/24/88)
In article <3290002@hpctdls.HP.COM> rbk@hpctdls.HP.COM (Richard Katz) writes: >>/ hpctdls:comp.lang.misc / phil@uxg.cso.uiuc.edu / 2:36 pm Dec 20, 1988 / > >>How did the := come into being in languages like Algol, Pascal, and Ada? > >I don't know how the := came into being, but I don't have any beef >about it. In fact, I think Pascal use of it is good. Pascal uses = >as a boolean operator and := as asignment. Why not think of the ":=" versus "=" question as a choice of whether or not to support operator overloading in the language. The "=" for assignment is a procedure, while the boolean operator is a function. Whether or not you like operator overloading, I think that the ":=" versus "=" question is reducible to another more basic question and should be discussed in that light. Of course, everything in this posting could be wrong. J Dana Eckart UUCP: ...!(gatech | pyrdc)!gmu90x!dana ...!pyrdc!nowhere!dana INTERNET: dana@gmu90x.gmu.edu SNAIL: P.O. Box 236/Fairfax, VA 22030-0236
flaps@dgp.toronto.edu (Alan J Rosenthal) (12/27/88)
In article <3290002@hpctdls.HP.COM> rbk@hpctdls.HP.COM (Richard Katz) writes: >First, := seems better since i = i + 1 looks real funny. C's solution to that is to introduce ``i += 1''. (Well, C didn't invent this I don't believe but it has it.) >Also, a nice feature is that 'if ( i := 10 )' will produce a syntax error in >Pascal while 'if ( i = 10 )' will produce an assignment in C, usually not >intended. No, this is not because of the different characters which make up the operator. This is because in C an assignment statement is an expression and in Pascal it is not. This is a completely separate question. (I personally think ``assignment'' and ``embedded assignment'' operators should look different, something I've never seen in the real world.) ajr -- "The goto statement has been the focus of much of this controversy." -- Aho & Ullman, Principles of Compiler Design, A-W 1977, page 54.
peter@ficc.uu.net (Peter da Silva) (12/27/88)
In article <3290002@hpctdls.HP.COM>, rbk@hpctdls.HP.COM (Richard Katz) writes: > as a boolean operator and := as asignment. First, := seems better > since i = i + 1 looks real funny. Also, a nice feature is that > 'if ( i := 10 )' will produce a syntax error in Pascal while > 'if ( i = 10 )' will produce an assignment in C, usually not > intended. FORTRAN uses .EQ. to make sure that there is no mixup This has nothing to do with :=/= versus =/==. This has to do with C being an expression-based language and Pascal being a statement-based language. There are expression-based languages which use := and allow you to say things like "if flag := f1 and f2 then...". Just so long as you have two tokens. If you want to flame a language, try BASIC ("if a = b then a = c"... the first is a comparison, the second an assignment). -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
nevin1@ihlpb.ATT.COM (Liber) (12/28/88)
In article <3290002@hpctdls.HP.COM> rbk@hpctdls.HP.COM (Richard Katz) writes: >I don't know how the := came into being, but I don't have any beef >about it. In fact, I think Pascal use of it is good. Pascal uses = >as a boolean operator and := as asignment. First, := seems better >since i = i + 1 looks real funny. It looks funny to me, too. I much prefer "i += 1", but I don't remember augmented assignment being legal in Pascal. >Also, a nice feature is that >'if ( i := 10 )' will produce a syntax error in Pascal while >'if ( i = 10 )' will produce an assignment in C, usually not >intended. This really has nothing to do with ":=" vs "=". C is an expression-based language; Pascal is not (by expression-based I mean that every operator returns a value that can be used as one of the parameters for another operator). In Pascal, just about (ie, I'm not 100% sure :-)) every use of ":=" could be replaced by "=" with no ambiguities arising (please don't flame me if there is an exception to this statement; it would not be difficult to change the language so that none of these ambiguities arise). Heck, even my TRS-80 Model I Level II BASIC could differentiate between these two cases! :-) -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
brooke@ingr.com. (Brooke King) (12/30/88)
In article <2286@garth.UUCP> smryan@garth.UUCP (Xxxxxx Xxxx) writes: | >How did the := come into being in languages like Algol, Pascal, and Ada? | | IAL 58. | | >I still prefer the way it is in C (and a little lesser so in Rexx and | | Booooo! Hisssss! | | It's all in how you read it. I read `a:=b' as `a becomes b' not `a equals b.' | `a equals b' is `a=b.' I read C's "a = b" and Pascal's "a := b" as "a receives b," "a receives b's value" or "a receives the value of b." I usually stick with "a receives b." I read C's "a == b" and Pascal's "a = b" as "a is b." In C, I make use of the preprocessor to avoid accidental "=" where I mean "==" -- I always use "IS" (# define IS ==) instead of "==" so I haven't made that mistake in seven years (the length of time I have been using the trick). No, it isn't original; a friend used a similar trick. I also use "ISNT" for "!=", "NOT" for "!", "AND" for "&&", and "OR" for "||". They all make reading logical expressions rather natural. They also help me avoid my mistyping bitwise {"&" "|"} operators for logical {"&&" "||"} operators and vice versa. | So what about the shift-key? We're all touch-typists, rught? I am, Mr. Ryan, but many of our coworkers are not. :-) ^^^^^ -- brooke@ingr.com uunet!ingr!brooke W+1 205 7727796 H+1 205 8950824
mason@tmsoft.uucp (Dave Mason) (12/30/88)
In article <2567@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >This has nothing to do with :=/= versus =/==. This has to do with C being an >expression-based language and Pascal being a statement-based language. There >are expression-based languages which use := and allow you to say things like >"if flag := f1 and f2 then...". What it really has to do with is that something that your fingers learn to do: if abc = def then ghi :=jkl; in Pascal becomes: if (abc = def) ghi := jkl; occasionally when you are writing in C (for the first 2-3 years after switching (may your Deity help you if you don't in fact switch, but alternate back and forth :-)). The compiler nicely points out the :=, but leaves you with the nasty bug: if (abc = def) ghi = jkl; which is your finger's mistake, not even your brain....can be a very hard bug to find. > >Just so long as you have two tokens. If you want to flame a language, try >BASIC ("if a = b then a = c"... the first is a comparison, the second an >assignment). If you want to flame a language, try PL/I: if if = then then then = else else else = if; (there may be some ';' missing, but this is an otherwise legal statement!) The problem is that there aren't any REAL keywords. The parser must be a zoo! (...and while we're PL/I bashing, how about: i = 25/3; which assigns some WEIRD value like 5 to i because of weird default typing & coercion rules!) But there are some 'features' :-) in the language: e.g. substr is a function that takes part of a string, and bit is a function that converts an integer into a string of bits: substr(bit(i),6,17) = substr(bit(j),3,17)) transfers a 17 bit field between part of two integers. Details may be off, as it's been about 5 years since I wrote my one (1) PL/I program (2000 lines!), but the principle's right. I think the committee that designed the language was on acid most of the time. ../Dave
eliot@phoenix.Princeton.EDU (Eliot Handelman) (12/31/88)
In article <2567@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >If you want to flame a language, try >BASIC ("if a = b then a = c"... the first is a comparison, the second an >assignment). In the only basic that I've ever used, your statement would read if a = b then let a = c. It was Spectrum ZX Basic and I had the bright idea of writing a lisp interpreter in it. The result was a nightmare.
bcw@rti.UUCP (Bruce Wright) (01/03/89)
In article <1988Dec30.025022.2883@tmsoft.uucp>, mason@tmsoft.uucp (Dave Mason) writes: > If you want to flame a language, try PL/I: > if if = then then then = else else else = if; > (there may be some ';' missing, but this is an otherwise legal statement!) > The problem is that there aren't any REAL keywords. The parser must be a zoo! Actually the statements would be written: if if = then then then = else ; else else = if ; Because of the use of the ";" character, the parser is not nearly as bad as it looks like at first (though I would be the first to admit that it's a bit more complex than something like Pascal where all the keywords are reserved). The motivation for not having reserved words (which PL/I shares with, for example, FORTRAN) can be seen very clearly in COBOL, where EVERYTHING is reserved; this makes each edition of the standard invalidate TONS of programs which happened to use words which are now reserved! The latest edition of the PL/I standard (ANSI X3.74-1987) uses this feature of the language to add a case statement (named SELECT in PL/I) which did not exist in earlier standards (it had been a nonstandard extension in IBM PL/I). If the language had had reserved keywords, this would have invalidated existing programs. There is some argument for not adding new constructs to a language, but instead designing new language from the ground up when certain design features show themselves to be useful. The major problem with this is that it invalidates even more code than an approach like PL/I or FORTRAN - and this can impose a major economic burden. No question that you get a more elegant language as a result; but as long as there is such an economic cost you will see interest in extending existing languages. > (...and while we're PL/I bashing, how about: > i = 25/3; > which assigns some WEIRD value like 5 to i because of weird default typing & > coercion rules!) Not true. The value assigned to i will be a FIXED DECIMAL number looking something like 8.33333333333333 where the number of 3's depends on the maximum numeric precision supported by the implementation. If i is an integer value of some kind (does not have any places to the right of the decimal point), this is truncated to 8; if i is floating point an appropriate approximation is selected. What you are probably thinking of is the expression: i = 25 + 1/3 ; which on the older PL/I standard required the raising of the FIXEDOVERFLOW condition! The problem is that by the PL/I rules for division, the "1/3" has a higher basic precision than the "25" (in fact it has the maximum precision supported by the implementation), and it runs out of digits in a rather counterintuitive way. The newer standard adjusted the meaning of the "/" operator to fix this and other problems with "/", at the risk of some incompatibility with older programs which were not conforming to standard usage and which relied on encountering such exceptions. So the situation is not as bad as you make it sound, though it is a bit odd. The basic problem is that fixed-point arithmetic (as opposed to integer and floating point arithmetic) is a fishy operation to begin with; if you want to see a real crock the designers of Ada got it even worse! > But there are some 'features' :-) in the language: e.g. substr is a function > that takes part of a string, and bit is a function that converts an integer > into a string of bits: > substr(bit(i),6,17) = substr(bit(j),3,17)) > transfers a 17 bit field between part of two integers. Details may be off, > as it's been about 5 years since I wrote my one (1) PL/I program (2000 lines!), > but the principle's right. Sorry but the principle is not right. "BIT" cannot be used as a pseudo- variable (as a target on the left-hand side of an assignment) in standard PL/I, though it is possible that the compiler you encountered would allow it. It is possible to use "UNSPEC" in a similar context; the use of this function/pseudovariable (which converts its argument to its internal format) automatically makes the program nonportable, and is probably questionable programming style as well (exception would be in some system programming applications where this type of escape mechanism might be needed). C has similar capabilities for bit manipulation (as does Ada in its verbose way), so if that's what you're complaining about you probably should include those languages as well. The PL/I definition of arithmetic is unnecessarily complex, but its definition of strings is one place I think that the designers did reasonably well. It's not as powerful as, for example, SNOBOL, but once you become familiar with the capabilities of PL/I string handling, the FORTRAN/Pascal/C models, although different from each other, all seem about equally infuriating. > I think the committee that designed the language > was on acid most of the time. Doubtful. However there is one comment apropos to large languages that I heard once: Algol-68 and PL/I have often been accused of being languages which have everything but the kitchen sink included in them. The designers of Ada decided to avoid this criticism by including the kitchen sink as well. Bruce C. Wright
ray@micomvax.UUCP (Ray Dunn) (01/07/89)
In article <3290002@hpctdls.HP.COM>, rbk@hpctdls.HP.COM (Richard Katz) writes: > 'if ( i := 10 )' will produce a syntax error in Pascal while > 'if ( i = 10 )' will produce an assignment in C, usually not > intended. FORTRAN uses .EQ. to make sure that there is no mixup In article <2567@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >This has nothing to do with :=/= versus =/==. This has to do with C being an >expression-based language and Pascal being a statement-based language. Certainly the Pascal *compiler* picks up the error because Pascal is statement based, however the compiler is hardly ever called upon to flag that error, because with :=/= programmers rarely *make* the error. In 'C' the problem arises both because it is expression based, allowing the "if (assignment-expression)" construct, *and* because the assignment operator is an overworked symbol which in many programming languages *and other environments* implies equality. >... If you want to flame a language, try >BASIC ("if a = b then a = c"... the first is a comparison, the second an >assignment). The interesting thing about this, contrary to the implication, is that it is neither ambiguous nor prone to create undetected errors. The multiple meanings of "=" are nicely distinguishable by context, even though using the same symbol for assignment and equality is dubious from a conceptual point of view. The =/== problem is not one of context dependancy nor of symbol over-use, it is one of *lack* of context dependancy which is not necessarily a bad thing in itself, and the "related" ambiguity of "=". If you look at 'C' and its use of =/== in a totally introverted fashion, then there *is* no problem. It is only because of the use of "=" in the world outside 'C' (and not only in the context of programming languages) that it becomes a problem in 'C' that "=" in the context of "if" means assignment rather than equality. -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090