Re: Prefix, infix and function-call and their implications in embedded language readability

On 2010-01-21, Peng Yu <pengyu.ut@gmail.com> wrote:
> Consider the following three expressions, which are valid C, mit-
> scheme and Mathematica expressions. There are of course many other
> expressions that express the same thing in other languages, or in the
> same language but other different ways.
>
> 3+2*5>7
> (> (+ 3 (* 2 5)) 7)
> Greater[Plus[3,Times[2,5]],7]
>
> Apparently, at least to me, the first expression is the most readable.


Really? What if we replace 2 3 5 7 by a b c d, and then change
the meaning of the operators, or give them a precedence you aren't
accustomed to?


What if 3+2*5>7 is actually a Smalltalk expression, such that it just
means ((3+2)*5)>7?


> One possible reason is that we learn this algebraic notation much
> earlier than the other two, which is in analogy to that we can respond
> to the native language (say, English) much faster than to a second
> language (say, French).


Another possible reason is that the algebraic notation has only a few
operators, whose precedence you have memorized (and are assuming to
hold true of the expression above).


Would it still be readable if the grammar had 500 operators, arranged into 200
precedence levels?


Another reason is that because you have a few operators, you can use special
glyphs for them, which are distinct from numbers and variables.


That second Lisp notation is unambigous. So we can replace all of the
non-punctuation symbols, and still recognize the tree shape as being the same,
provided we keep the parentheses in the printed notation as they are:


    (> (+ 3 (* 2 5)) 7)


    -> substitute generated symbols for all non-nil atoms ->


    (G0001 (G0002 G0003 (G0004 G0005 G0006)) G0007)


I still know that the major constituent of the expression is G0001,
whose arguments are (G0002 ....) and G0007.


If we substitute the non-punctuation symbols of the infix expression, we are
lost; there is no explicit grouping there to retain:


    G0001 G0002 G0003 G0004 G0005 G0006 G0007


Can you remember that G0002 and G0004 are binary operators,
and that G0004 has a higher precedence than G0002?


See, the amount of assumption is much smaller for the S-exp notation.
We assume that the parentheses group and that space separates elements.
That's it. The infix means we assume.


So what happens with operator precedence is that when the number of meanings we
want to use exceeds the number of operators, we can't invent new operators, so
we start overloading the meanings of the existing ones: a + b adds
strings together, or performs set union, etc. In math is not so bad because in
math you can invent new glyphs, make use of different typefaces and alphabets,
and make use of two dimensions, etc. If you want some different kind of plus,
you can put a circle or box around the plus symbol and there you go: new glyph.


When prefix notations get long, we can easily break them into multiple lines
using a few simple guidelines, e.g.:


    (G0001 (G0002 G0003
                                (G0004 G0005 G0006))
                  G0007)


This we can easily visualize the structure as a tree printed sideways.


Consider that all Scheme code is written in that notation, not just small
expressions. The notation scales to express everything in the program.


The infix notation like a+b*c>7 is only /locally/ readable: small,
simple instances that fit onto less than about half a line of text.


It does not scale to large expressions, and it's not suitable for writing
expressing entire programs, which is why languages which have expressions
typically provide other constructs like statements and declarations for
structuring the rest of the program.


> Readability affects the programmer productivity.


That's only one kind of readability, which we can call ``micro-readability'':
the readability of a small expression that occupies about a third of a line of
text in your editor.


Microreadability is significant, but not as much as you think.


A large program is not readable no matter what notation it is written in. You
can't just sit down and read 500,000 lines of code, and grasp it all as a unit.
So being able to pick out a readable 15 character subsequence of that program
doesn't actually buy you as much as you think.


Suppose that small subexpressions found in a 500,000 line program are all
beautifully micro-readable. Suppose you need to make a small change to one of
them. What if it turns out that the program has 10,000 other expressions
similar to that one (but not exactly the same), and they /all/ have to be found
and changed in an analogous way in order for your proposed change to work
properly? Oops.


Large program structure and semantics is what affects productivity.


It's not how micro-readable it is, but how little of it you have to read,
understand and rewrite to implement a new requirement, or fix a bug.


> Since embedded language can be embedded in a computer language, such
> scheme and C++, the choice of prefix, infix and function-call can
> profound affect the readability of the embedded language. I haven't
> found any previous references on this issue. Could somebody
> recommend me some if there are?


If you don't have any references, how can you be sure that the effect of infix
versus prefix is ``profound''?


People working in, say, Java don't struggle any more or less than people
working in Scheme, in terms of just cranking out raw code and understanding
what they have written.


They struggle differently on a higher semantic level.
> 3+2*5>7
[ASSIGN 3 TO CONSTANT-THREE. ASSIGN 2 TO CONSTANT-TWO. ASSIGN 5 TO CONSTANT-FIVE.
MULTIPLY CONSTANT-TWO BY CONSTANT-FIVE GIVING INTERMEDIATE-FACTOR. ADD CONSTANT-THREE
TO INTERMEDIATE-FACTOR GIVING SUM-VALUE. IF SUM-VALUE IS GREATER THAN 7 GOTO ANOTHER-PLACE.


Now THAT's readable. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.