Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Mark Leighton Fisher (4252)

Mark Leighton Fisher
  (email not shown publicly)

I am a Systems Engineer at Regenstrief Institute []. I also own Fisher's Creek Consulting [].
Friday May 11, 2007
11:59 AM

Perl 6 and Why Infix Notation is Better

[ #33253 ]

Infix notation is better (in my possibly uninformed opinion) because of contrast and tracking. Infix notation alternates between operands and operators, whereas prefix and postfix notations group operands together, separating operands from their operators in all but the simplest expressions. The contrast between operands and operators makes code easier to read. This alternation of operands and operators also means there are fewer things to keep track of at any time, which means the code is simpler to read. There are fewer things to track at one time because you can parse up infix notation into separate, composable blocks:

   (HAS-A:) (sin(x) * 4.5) / 3.14159) + (arctan(y) * 20)

while prefix and postfix notation force composability through something like an inheritance tactic:

    (IS-A:) (+
                  (sin x)
                  (arctan y)
                (+ 3 4.5)

makes (for example) the arctan expression into a child of the whole expression, leading to (in complicated expressions) having an inheritance tree to track rather than the (more) separate infix expressions).

I am harping on the readability of code because, once you have done the initial writing of your code, you will spend more time reading your code than writing new code:

Programs must be written for people to read, and only incidentally for machines to execute.
Abelson and Sussman

LISP S-Expressions made it possible for people other than hard-core compiler gurus to extend the language, as S-Expressions are easy to parse without a sophisticated compiler infrastructure in place. However, we are not in 1960 this is 2007, with compiler tools aplenty including our own Perl 6. If I have understood correctly, the Perl 6 grammar will be a "read-write" grammar programmers will be able to not only read the grammar, but modify it to suit their projects.

It may be that I haven't looked hard enough, but I think the Perl 6 grammar alone will set it well above other infix languages in how easy it will be to extend the language. This helps ensure the evolution of Perl, as many programmers can experiment with creating new Perl features in a clean fashion (as opposed to Perl source filters, LISP macros, etc. which are hard to get correct and useful at the same time).

The programming community has a debt of gratitude to S-Expressions, but our tools have advanced to the point where we can have both the easier infix notation and an extendable programming language Perl 6.

(If I'm wrong about this, please let me know.)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • This helps ensure the evolution of Perl, as many programmers can experiment with creating new Perl features in a clean fashion...

    The cleanliness of their results depends on their skill. At least you know if your Perl 6 programs stop working, you have a grammar problem (whereas I have to work fairly hard to make a completely invalid Lisp program; maybe I'm bad at macros).

    • Grammar-level errors are one reason why I'm excited about Perl 6. I still have bad memories of maintaining C macros (and even a homegrown, standards-compliant C preprocessor). Getting your grammar errors at the grammar level, rather than debugging a macro that preprocesses and compiles fine but does not work, sounds like working at the Right Level to me.