brian will . net

Expressions, expressions, expressions

The most common oversight in beginning-programming education is that most instructors and most books fail to emphasize the concept of expressions. From my own learning experience and from talking to classmates, it’s very rare, for instance, for learners to think of the of the function name in a call as the operator and its arguments its operands. Students also fail to grasp the basic idea that all operands are of a type and that an expression, no matter how complex, evaluates into a single typed value.

The benefit to giving learners a thorough understanding of expressions up front is that it then becomes easy in most languages to explain a good number of other rules. For example, when explaining conditional expressions, all you have to say is that it’s an expression whose evaluated value is then interpreted as true or false according to such-and-such rules. You shouldn’t then have to explicitly tell learners that they can include function calls in the expression or (in some languages) assignments. Most importantly, learners can begin to see a conceptual unity in the language.

With this in mind, it occurs to me that Pygeon (my educational language [see previous post]) should use prefix notation rather than the usual infix notation. Pygeon’s prefix notation would differ in a few key ways from that found in Lisp:

• Pygeon is still statement-based, so control flow (’if’, ‘while’, etc.) is kept conceptually separate.
• The outer expression of a statement need not be surrounded in parentheses.
• Operators will all be designated by name rather than symbol, i.e. the addition operator will be add. Even operators like . and [] are expressed as what appear to be built-in functions, e.g. indexing the fourth member of an array would be written: (member arr 3) .

It follows that, for consistency, function calls should adopt the Lisp prefix style, including the lack of commas between arguments.

The basic benefit to these decisions is that it frees students from having to think about syntax: using named operators and prefix notation may require more parentheses and verbosity than most experienced programmers would want to deal with on an extensive basis, but the advantage for learners are considerable—at the very least, prefix notation frees students from the distraction of an order of precedence. Perhaps more importantly, I think learners can too easily fail to see the conceptual parallel between an operator and its operands and a function and its arguments; the difference between the two really is just that the built-in operators of a language are built-in, use a special syntax for convenience/aesthetic reasons, and are typically implemented differently from function calls to avoid the same overhead.

Of course, learners eventually will move on to languages with the more typical infix notation, so you might object that students shouldn’t be deprived of infix. While I do believe prefix notation lays bare the concepts of expressions in a way that infix does not, I actually think the optimum approach is to present them side-by-side, no matter what the language being taught, for this is an excellent example of where learning more material makes learning easier rather than harder because the concepts are best understood presented in contrast with near-neighbors and alternatives. Prefix notation offers the purer syntax for expressions while infix is the more familiar.