jack@boring.UUCP (08/11/85)
Something that caught my attention a while ago is the following:
Why do most programming languages do assignments like
<destination> <assign-operator> <expression>
This has two major disadvantages over
<expression> <assign-operator> <destination>
in my opinion.
1. The second case is simpler to produce good code for.
In the first case, the compiler should remember the <destination>
expression, which may involve putting it on the stack or something
like that if the <expression> is very complicated.
2. (More important) The second case is much easier to read.
Everyone (well, almost everyone) reads and writes a program
left-to-right:
if(a+b == 3)
Calculate a+b, then compare to 3, as opposed to
if(3 == a+b)
Remember 3 for later, calculate a+b, compare to what we remembered
previously.
I tend to read a statement like
foo[i+j].bar->bletch = a+b in the order
2 3 4 5 1
(although it could be discussed that 2 and 3 should be the other way
around).
So, wouldn't
a+b => foo[i+j].bar->bletch
be more logical?
Moreover, I what about the infamous C construction
a[i++] = i
I remember seeing a language with the second type assigments once,
but it hasn't seemed to catch on.
Does anyone know any good reasons for this?
--
Jack Jansen, jack@mcvax.UUCP
The shell is my oyster.quiroz@rochester.UUCP (Cesar Quiroz) (08/11/85)
From article <6571@boring.UUCP> (jack@mcvax.UUCP (Jack Jansen)): > >Something that caught my attention a while ago is the following: > >Why do most programming languages do assignments like > <destination> <assign-operator> <expression> > > ... > >1. The second case is simpler to produce good code for. > In the first case, the compiler should remember the <destination> > expression, which may involve putting it on the stack or something > like that if the <expression> is very complicated. Not really relevant. Given languages with sufficiently powerful lhs and rhs expressions, either order will force the compiler to keep context. Indeed, this cannot be a heavy factor in any but the most restricted architectures (Try run one such in an 8k machine and you may find the savings useful. Then again, you may better not use other than assembler in that case.) For starters, which side is simpler in: *x++ = *y++; /* looks familiar? */ ? I feel more interested by your second point: >2. (More important) The second case is much easier to read. > Everyone (well, almost everyone) reads and writes a program ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: quantifier used in risky context. line above. processing continues. > left-to-right: > ... > Recent postings seem to indicate that people split roughly in two schools of opinion : those who will give a try to any syntax, given that the human brain tends to accomodate very well to learning new notations, and those that won't spend any time learning C because they already read Pascal. I agree that I would find easier to read a programming notation that were bidimensional in its text, with the same preferred scan order orientation: left-to-right and top-to-bottom. But let me be afraid that no quantifier over the universe of programmers will be left unchallenged by this network... I myself enjoy jumping from C to Lisp and have been known for casual contacts with APL, FP (and even COBOL!). More below. >I remember seeing a language with the second type assigments once, >but it hasn't seemed to catch on. > >Does anyone know any good reasons for this? I will bet that there are some historical reasons. First, primitive parsers were in desperate need for clean anchor points. So, the significance of new lines in Fortran. Correspondingly, they wanted to be able to decide about the statement type with little or no context. This appeared in the form of keywords or reserved symbols appearing as far to the left as was convenient. As examples, BASIC's 'let' and FORTRAN's 'call' (or the mysterious commas, mostly optional and normally forgotten, in 'do' and both the computed and the assigned 'go to's). (Anecdotally, I was once bitten by a compiler that wouldn't take this: identifier *= atrociously long Fortran expression complaining that it couldn't identify the statement type on the basis of the first card alone.) Maybe somebody experienced with precedence or recursive- descent only parsers can tell us if this "let me know soon" was really relevant in the early designs. Your idea has interesting interactions with value-returning assignments. For instance, good old UPL had 2 assignment operators: ":=" and "::=", called "delete right" and "delete left" (though I no longer remember which is which). One returned the final value stored in the left member ("delete right"), the other kept around the value before conversions. Let's assume that a language is worked around your suggestion of left-to-right preference (which could mean that the value "surviving" an assignment is the rightmost one), then we might have "directional" assignments (say "->" and "<-"), with neat and wizardesque consequences: float x; int i; f1 (int arg); or f2 (float arg); /* assign value of i to x and call one of these functions */ f1 (x<-i); /* remember, i survives to be passed to f1 */ or f2 (i->x); /* here we need a float, so we assign in the other order! */ reversing UPL's style (instead of always assigning right-to-left and deciding which member is returned, we could always return the "last" member, and have to decide on the direction of the assignment.) In this light, what does everyone feel about x +=: y; /* add y to x, return old y */ or even the canonical x :-) y ; /* do something to x and y and return whatever is needed */? I'd like to see more of this subject being discussed. (Even flames, not to break old habits.) Cesar -- Cesar Augusto Quiroz Gonzalez Department of Computer Science {allegra|seismo}!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@ROCHESTER
smh@mit-eddie.UUCP (Steven M. Haflich) (08/11/85)
On the merits of coding assignment operations: <expr> = <variable> The argument that this saves work for the compiler is uncompelling. However, code readability is crucial. Code is typically left justified, modulo indentation for block structure, but the right margin is ragged. Placing the assignment target at the block-justified left margin facilitates answering questions like "When was this variable last set?" Also, remember that any argument that assignment should be notated in execution order (for benefit of either mechanical or human reader) would seem to extend to parentheses. The logical conclusion is that all code should be written in reverse Polish. True, that simplifies compilers, but....
johnl@ima.UUCP (08/12/85)
/* Written 5:18 pm Aug 10, 1985 by jack@boring in ima:net.lang */ > Something that caught my attention a while ago is the following: > Why do most programming languages do assignments like > <destination> <assign-operator> <expression> Well, actually, because Fortran did it that way in 1957, and Algol-58 did it that way in 1958, and all algebraic languages since then appear to have been designed by people who already knew one or the other. The Fortran statement "A = B + C" roughly translates into the following Cobol (1959): ADD APPLES-ORDERED AND BLANKETS-RECEIVED GIVING CATTLE-DELIVERED. But since scientific and systems programmers have always had this thing about how nothing in Cobol could possibly be any good, it never caught on in the Fortran and Algol world. John Levine, ima!johnl PS: Yes, I know Cobol has the COMPUTE statement which uses Fortran assignment syntax, but Cobol programmers rarely use it.
darryl@ISM780.UUCP (08/12/85)
I suggest that, instead of everyone else learning a new programming language, you might be interested in learning one of the many semetic languages that read right to left. After that, you'd probrably be most comfortable coding in APL, which has guaranteed right to left evaluation. In APL, i_i+1,0 rho a[i] _ i does just exactly what you expect it to. Of course, nobody writes it that way in APL... (Oh, interpret the "_"s to be left arrows; anyone remember when teletypes had left arrows and not underscores?) --Darryl Richman, INTERACTIVE Systems Corp. ...!cca!ima!ism780!darryl The views expressed above are my opinions only.
oacb2@ut-ngp.UTEXAS (oacb2) (08/12/85)
> I will bet that there are some historical reasons. First, primitive parsers > were in desperate need for clean anchor points. So, the significance of new > lines in Fortran. Correspondingly, they wanted to be able to decide about > the statement type with little or no context. I find it difficult to believe this consideration had much to do with writing a = b + c rather than b + c = a in FORTRAN. In fact, in a number of places (e.g., having no reserved words) it almost looks like the designers went out of their way to make it difficult to parse. For example, after scanning call it(5) we still don't know what kind of statement we're dealing with. The line could continue call it(5) = 7.0 It's incredible that anyone worried about making it easy to identify statements would design a DO statement that cannot be identified until the comma between the inital and ending value is scanned. FORTRAN is full of things like this. It's an extremely easy excercise to write a FORTRAN program that a human finds almost unreadable just by using keywords and spaces creatively. I'd guess that the order of assignment statements came largely from the usual practice in mathematics of writing equations which have one side a single variable with the variable on the left. -- Mike Rubenstein, OACB, UT Medical Branch, Galveston TX 77550
steven@boring.UUCP (08/13/85)
In article <6571@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes: > Something that caught my attention a while ago is the following: > > Why do most programming languages do assignments like > <destination> <assign-operator> <expression> [rather than] > <expression> <assign-operator> <destination> ... > I remember seeing a language with the second type assigments once, > but it hasn't seemed to catch on. I've used a couple of languages that assigned that way round. But what about COBOL? Not caught on, you say? Might I also point out that the new language B (not the predecessor of C - no flames please), developed just down the corridor from you, also has the this type of assignment? Steven Pemberton, CWI, Amsterdam; steven@mcvax.UUCP (Well, *someone* had to say it.) P.S. Actually I can think of a reason: if assignments were the other way round, you'd have your Lvalues on the right, and your Rvalues on the left; clearly undesirable :-).
haahr@macbeth.UUCP (Paul Haahr) (08/13/85)
In article <6571@boring.UUCP> Jack Jansen (mcvax!jack) writes: > Why do most programming languages do assignments like > <destination> <assign-operator> <expression> > This has two major disadvantages over > <expression> <assign-operator> <destination> > in my opinion. > ... > I remember seeing a language with the second type assigments once, > but it hasn't seemed to catch on. I can think of one in which a similar syntax has caught on. Consider: echo 3 > a (a = 3) echo 5 > b (b = 5) cat a | add b > c (c = 8) cat a | sub b | tee d | add `echo 4` > e (e = (d = a - b) + 4) where add and sub are filters that numerically add (substract) the values from the file presented as an argument to the standard input values. Arithmetic is not the typical use of of the shell, but the pipe notation is flexible enough (because all it really is is another notation for calling functions, as is operator infix notation). I like shell/pipe syntax better (as a rule of thumb) than operator notation, and agree that left to right could be more intuitive than right to left. However, it will take more than slight notational convenience to change the world. my suggestion: write a good, general purpose programming language that uses this notation. use it for a while. if you and other people like it, great. if not, all you've done is invented another dvorak keyboard. -- Paul Haahr ..!princeton!macbeth!haahr
barmar@mit-eddie.UUCP (Barry Margolin) (08/13/85)
In article <6571@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes: >Why do most programming languages do assignments like > <destination> <assign-operator> <expression> I think that it is mostly due to the legacy of Fortran, Algol, PL/I, etc. As to why these languages do it this way, I suspect that it has to do with mathematical notation. Mathematicians often name quantities with statements of the form Let <var> = <expression> or Let <var> be <description> (e.g. "Let R be the set of real numbers"). -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
emigh@ecsvax.UUCP (Ted Emigh) (08/13/85)
From article <6571@boring.UUCP> (jack@mcvax.UUCP (Jack Jansen)): > >Something that caught my attention a while ago is the following: > >Why do most programming languages do assignments like > <destination> <assign-operator> <expression> The suggestion is that <expression> <assign-operator> <destination> might be a better order. As someone who has done a lot of scientific programming, I find the former way much easier to read in debugging programs. In such cases, I usually am interested in a few control variables (loop counters, etc), and in when they change values. Much of the rest of the programs are filled with various essentially irrelevant material (such as the actual scientific computations). It is much easier for *ME* to parse the line and ignore the irrelevant sections if the destination appears on the left. Have you ever looked through a program trying to find the rightmost reference in a set of lines of varying lengths? Particularly if many lines have comments in the latter spaces on the line? --Ted-- -- Ted H. Emigh Genetics and Statistics, North Carolina State U, Raleigh NC USENET: {akgua decvax duke ihnp4 unc}!mcnc!ecsvax!emigh ARPA: decvax!mcnc!ecsvax!emigh@BERKELEY BITNET: nemigh@tucc
msb@lsuc.UUCP (Mark Brader) (08/13/85)
Jack Jansen asks why so many languages have assignments with the destination on the left so that, in some sense, the statement must be executed right to left. I think there are two reasons. First is the parallel with mathematical notation where the unknowns conventionally go on the left; the assignment destination is like an unknown since it's just being computed. Second and more important, statements are aligned by the left, and the most important thing to know in a short segment of a program is what variables are changed. So the destination-on-the-left means that those variables are nicely lined up for you. Compare: apples = oranges + lemons; pairs = triplets * quartets[quintets]; answer -= 42; and: add oranges, lemons giving apples. multiply triplets, quartets(quintets) giving pairs. subtract 42 from answer. I think it's much easier to see in the C example that it's apples, pairs, and answer that are being computed than it is in the COBOL example. Mark Brader
fsks@unc.UUCP (Frank Silbermann) (08/13/85)
>> Why do most programming languages do assignments like >> <destination> <assign-operator> <expression> >[rather than] >> <expression> <assign-operator> <destination> >... >> I remember seeing a language with the second type assigments once, >> but it hasn't seemed to catch on. In article <6572@boring.UUCP> steven@boring.UUCP (Steven Pemberton) writes: > >P.S. Actually I can think of a reason: if assignments were the other way >round, you'd have your Lvalues on the right, and your Rvalues on the left; >clearly undesirable :-). This makes more sense than you think. When debugging, you often need to scan the program text to find the last place a variable's value was set. You rarely if ever scan the listing for the last place the value was referenced. That is, you're more likely to be searching for an Lvalue when quickly skimming over the code. These Lvalues are easier to pick out when set flush against the margin. Frank Silbermann
kurt@fluke.UUCP (Kurt Guntheroth) (08/13/85)
I once wrote a language in which assignment went left-to-right. I had also
noticed that most constructs go left-to-right and wanted the language to be
totally consistent.
WHAT A MISTAKE!!!! There were basically two problems. The first was that I
had to re-learn how to write assignments. Every time I wrote a program, I
had at least one syntax error result from doing my assignments backwards.
The second problem was that the targets of the assignments (the interesting
part) didn't line up on the page. Look at
a = 0
b = Z[i,j,k] + C[i,j,l]
c = -b/2ac
and now (I change only the assignment operator and direction and) look at
0 -> z
Z[i,j,k] + C[i,j,l] -> b
-b/2ac -> c
See? This is simply a case in which you want to go right-to-left. By the
way, code generation wasn't significantly easier, and if you parse to trees,
there is no difference at all.
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtfranka@mmintl.UUCP (Frank Adams) (08/13/85)
In article <10984@rochester.UUCP> quiroz@rochester.UUCP (Cesar Quiroz) writes: > Let's assume that a language >is worked around your suggestion of left-to-right preference (which could mean >that the value "surviving" an assignment is the rightmost one), then we might >have "directional" assignments (say "->" and "<-"), with neat and wizardesque >consequences: > > float x; > int i; > f1 (int arg); >or > f2 (float arg); > > /* assign value of i to x and call one of these functions */ > f1 (x<-i); /* remember, i survives to be passed to f1 */ >or > f2 (i->x); /* here we need a float, so we assign in the other order! */ The problem is, I would expect these to work the other way; that is, x<-i is a float, and i->x is an integer. I think this notation is inherently confusing. (But that never stopped language designers before :-) Actually, I think the left assignment is usually more natural. Most of the time, I don't say "now I want to compute 'b^2-4*a*c'; now what shall I call the result? How about 'discrim.'" Instead, I say, "Now I want to compute the discriminant, which is in the variable 'discrim'; now what is the formula for it? Ah, 'b^2-4*a*c'". I might want a right-pointing assignment operator to create a temporary variable; the type of the variable would be the type of the expression assigned to it.
weltyrp@rpics.UUCP (Richard Welty) (08/14/85)
> I will bet that there are some historical reasons. First, primitive parsers > were in desperate need for clean anchor points. So, the significance of new > lines in Fortran. Correspondingly, they wanted to be able to decide about > the statement type with little or no context. This appeared in the form of > keywords or reserved symbols appearing as far to the left as was convenient. > As examples, BASIC's 'let' and FORTRAN's 'call' (or the mysterious commas, > mostly optional and normally forgotten, in 'do' and both the computed and the > assigned 'go to's). (Anecdotally, I was once bitten by a compiler that wouldn't > take this: > > identifier > *= atrociously long Fortran expression > Actually, many early compiler were completely ad-hoc (no formal model was used). For example, the Honeywell Series 16 Compiler expected to know the statement type after parsing the first line of each statement. If it didn't, well life sucks. In the same compiler, only the first four characters of keywords at the beginning of lines were examined. Thus, the following statement would produce the following results: INTEGR ABC, DEF the variables BC and DEF were declared integers (INTE was checked, and the next two characters were skipped). This compiler was later extensively modified to become the first prime fortran compiler, but most of the really braindamaged parts got patched up at this point in time ... -- Rich Welty (I am both a part-time grad student at RPI and a full-time employee of a local CAE firm, and opinions expressed herein have nothing to do with anything at all) CSNet: weltyrp@rpi ArpaNet: weltyrp.rpi@csnet-relay UUCP: seismo!rpics!weltyrp
peter@baylor.UUCP (Peter da Silva) (08/14/85)
Anyone remember the languages "bloop, floop, and gloop" from GEB?
a + b => c;
Also, in FORTH (which doesn't really have any syntax, but what the hell):
a b + c !
--
Peter da Silva (the mad Australian)
UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
MCI: PDASILVA; CIS: 70216,1076rpw3@redwood.UUCP (Rob Warnock) (08/16/85)
Historical Note: The programming language "MARY" (Mark Rain, Reidar
Conradi, Per Holager, and maybe others, circa 1972) did the assignment
operator left-to-right, but the definition operator of defining local
variables of "const" was right-to-left (as in C initializers). Example:
int i := 5;
int j;
defines "i" to be the constant "5" (for the scope of "i"), while
"j" is a "variable". The value of "j" could be set as follows:
i + 5 =: j;
This was intended to mirror the way assignment is done in assembly
language. (MARY is a systems implementation language).
It is interesting that some rather bizarre things could be done in MARY
that are rare in higher-level languages but common in assembler, due to the
left-to-right assignment and the strange (to most of us) idea in MARY that
labels and "goto"s are typed and carry values. In MARY it is legal to say:
int x, y, z, w;
label int foo;
...
if y > 0 then y + 3 go foo;
x + 37 foo: + z =: w;
so that if the goto is taken, the effect is
(y + 3) + z =: w;
and if the goto did not branch, you get the effect
(x + 37) + z =: w;
This is exactly the same as in assembler, where sometimes one
computes a partial result and then jumps into some place to
finish the computation and store a result. MARY just happens
to have strong typing of the goto and label to "clean up"
that notion a bit. Yes, I suppose that putting a label in
an expression must cause a cast of whatever is to the left of
the label to the type of the label! So that
3.12 foo: + 4.23 =: q;
would have to cast 3.12 to int (since "foo" is int) and then float
the result. This is necessary since "foo" may be jumped to with
an int value!
Anyway, COBOL wasn't the only language with left-to-right assignment...
Rob Warnock
Systems Architecture Consultant
UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD: (415)572-2607
USPS: 510 Trinidad Lane, Foster City, CA 94404
References:
R. Conradi & P. Holager, "A Study Of MARY's Data Types in a Systems
Programming Application", 24 July 1973. [Published in "Machine
Oriented Higher Level Languages", van der Poel & Maarssen, eds.,
North-Holland Publishing Co., 1974.]
M. Rain & P. Holager, "The Most Present Recent Final Word about
Labels in MARY", Machine Oriented Languages Bulletin #1,
October 1972. [ Reference found in M. Rains, "A Possible
Resolution of the Subroutine Calling Interface Problem
In Machine Oriented Languages", in "M.O.H.H.L.", op. cit.]jack@boring.UUCP (08/18/85)
It seems that the most common reply is either "Cuz Fortan and
mathematicians do it that way" or "Then it's easier to find the
places where a variable is assigned".
I do agree on the first argument, although I don't think it's
really a *good* reason, but not on the second.
Just think of scanf("%d",&foo); i=foo++; while(bar)foo=getc();
to show a few C examples.
Scanning the left margin to find places where a variable is changed
is very dangerous, since you'll miss a lot, and, moreover, it's
probably the most interesting changes that you miss.
Also, I just thought of another advantage of righthandside assignments:
You don't need the funny left associative operators anymore.
Also, think of the joys of being able to say
if( fopen("foobar","r") => infile == NULL ) scream();
--
Jack Jansen, jack@mcvax.UUCP
The shell is my oyster.peter@baylor.UUCP (Peter da Silva) (08/18/85)
> computations). It is much easier for *ME* to parse the line and ignore > the irrelevant sections if the destination appears on the left. Have you > ever looked through a program trying to find the rightmost reference in > a set of lines of varying lengths? Particularly if many lines have > comments in the latter spaces on the line? So right-justify your programs! Make nroff a programming aid! :-> -- Peter da Silva (the mad Australian werewolf) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
matt@oddjob.UUCP (Matt Crawford) (08/19/85)
I like the ICON operator "<->". The statement "x <-> y" will swap the values (and types) of x and y, and swap them back again later if the program fails back to that point. What could be clearer? :-]
franka@mmintl.UUCP (Frank Adams) (08/20/85)
In article <29800001@ISM780.UUCP> darryl@ISM780.UUCP writes: >In APL, i_i+1,0 rho a[i] _ i does just exactly what you expect it to. >Of course, nobody writes it that way in APL... (Oh, interpret the "_"s >to be left arrows; anyone remember when teletypes had left arrows and >not underscores?) Well, not quite what you expect; if i was a scalar before, it is now a vector with 1 element. And if i is a two dimensional array, you will get an error. (I realize this wasn't intended as an example of good programming practice; but it is a good example of bad programming practice.)
biep@klipper.UUCP (J. A. "Biep" Durieux) (08/20/85)
[Hey, daddy, what is that line for? - Well, sun, did I never tell you about
the dreadful line-eater? ]
Of course, if one does assignments left to right, one has to write
right margin adjusted (and indented) code.
--
Biep.
{seismo|decvax|philabs|garfield|okstate}!mcvax!vu44!klipper!biep
Is the difference between a difference of degree and a differ-
ence of sorts a difference of degree or a difference of sorts?jbn@wdl1.UUCP (08/23/85)
It's been done. NELIAC, an early Algol dialect with a singularly
simple compiler, used a right arrow as the assignment operator and placed
the source on the left and the destination on the right. This was about
1960; the disappearance of the right arrow when character sets became
standardized seemed to kill off interest in NELIAC and assignments of this
type along with it.
Regarding COBOL-60: There are all these dummies running around touting
``natural language interfaces'' that are just keyword-driven parsers with
some noise words. That's been done too. Here's some COBOL-60:
Assignment:
MOVE 100 TO X.
Arithmetic:
ADD 1 TO A.
SUBTRACT 1 FROM A GIVING B.
DIVIDE A BY B ON OVERFLOW STOP RUN.
MULTIPLY CORRESPONDING TABLE-1 BY TABLE-2 GIVING TABLE-3;
Subroutine call:
PERFORM ZILCH.
Code patching:
ALTER ZILCH TO PROCEED THROUGH ALTERNATE-CODE-SECTION.
All this junk has been taken out of the language. One now writes
COMPUTE X=A+1.
just like everybody else.
John Naglesteiny@scc.UUCP (Don Steiny) (08/24/85)
> > In article <6571@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes: > >Why do most programming languages do assignments like > > <destination> <assign-operator> <expression> > > I think that it is mostly due to the legacy of Fortran, Algol, PL/I, > etc. As to why these languages do it this way, I suspect that it has to > do with mathematical notation. > Barry Margolin In English we say: Fred is fat. Black is white. and generally ascribe the qualities on the right to the noun on the left. Why would you want to do it another way in a programming language? -- scc!steiny Don Steiny @ Don Steiny Software 109 Torrey Pine Terrace Santa Cruz, Calif. 95060 (408) 425-0382 (also: hplabs!hpda!hpdsqb!steiny)
guy@sun.uucp (Guy Harris) (08/25/85)
> All this junk has been taken out of the language. One now writes > > COMPUTE X=A+1. > > just like everybody else. I'll assume you really meant to say A more conventional assignment has been added to the language. One now can write... All that junk is still in the language, and I'm sure is still used by lots of people. One hopes they've been disabused of the notion that anybody who can read English can read COBOL code, however... Guy Harris
steven@boring.UUCP (08/30/85)
In article <543@scc.UUCP> steiny@scc.UUCP (Don Steiny) writes: > In English we say: > > Fred is fat. > Black is white. > > and generally ascribe the qualities on the right to the noun on > the left. Why would you want to do it another way in a programming > language? But we also say things like Put another coin in the juke-box Calculate how much you owe me, and deposit it in my account Send this message to my mother. In "a=1", 1 is not a quality of a, but something stored there for awhile. Steven Pemberton, CWI, Amsterdam; steven@mcvax.uucp
arndt@ttds.UUCP (Arndt Jonasson) (09/09/85)
In article <400@baylor.UUCP> peter@baylor.UUCP (Peter da Silva) writes: >Anyone remember the languages "bloop, floop, and gloop" from GEB? > > a + b => c; > >Also, in FORTH (which doesn't really have any syntax, but what the hell): > > a b + c ! And in TECO, of course, you write a+b Uc TECO doesn't really have a syntax either, though. And in DDT (which has a syntax): a+b<c: What about Prolog? A=4711 or 4711=A. Same thing (although "assignment" might not be the right word...) --- Arndt Jonasson ZYX Research, Stockholm UUCP: {decvax, philabs}!mcvax!enea!ttds!arndt