Hacker News Reader

Comment by Zambyte | Hacker News Reader

It is interesting to me that prefix notation gets brought up so much in the context of Lisp. Most operations in most languages use prefix notation (function calls, procedure calls, method calls, and most macro systems). The only thing that makes Lisp unique in this context is that it also makes arithmetic operations prefix. This is just the natural side effect of treating "primitive operators" as first class functions. It's something that other languages that treat these operators as non-primitive constructs awkwardly work around, like some syntax magic in Haskell or operator overloading in other languages.

What makes Lisp macros so intuitive is not the prefix notation, it's the homoiconicity of the language. Writing a macro is just a list operation, where the familiar map / filter / reduce applies.

View on HN

What makes Lisp macros so intuitive is not the prefix notation

The culture is the ultimate "reality distortion field." Prefix notation would be seen as intuitive, if that were culturally established. We'd see something like PEMDAS as arbitrary and silly.

Just look at how much content there is around PEMDAS and interpretation of math problems. Clearly, it really isn't "intuitive." We just have this enshrined in the culture. (That said, one of the biggest UX mistakes the designers of Smalltalk made, was to eschew operator precedence!)

My intention wasn't to argue whether or not prefix notation is intuitive. The point I wanted to make was the intuitiveness of Lisp macros is mostly unrelated to the use of prefix notation. Homoiconicity matters a lot more for macros.

I love prefix-notation for arithmetic, not just because it prevents the need for disambiguating precedence.

Subjective, I know, but I think (+ 1 2 3 4) is way nicer than (1 + 2 + 3 + 4).

When dealing with pure functions, there is also no ambiguity for f(g(1), h(i(2), 3), j(4)). In both cases, prefix notation removes ambiguity.

For me, it's concatenative languages. Grammar so simple that BNF is of dubious usage.

4 3 2 1 + + +

My problem with prefix, is simply that my mind does not think in prefix.

If I have to write 1 + 2 * 5 - 3, I'm not going to "start" with *.

I will type:

   (+ 1 2<-<-(* ^E 5) <-<-<-<-<-<-<-(- ^E 3))

It indicative of how I'm thinking about it (regardless of how the navigation is done).

I just have a lot of those starts and stops when converting infix to prefix in my tiny Piglet brain.

That said, as a general rule, yea, I like (+ 1 2 3 4) and its ilk. It takes a bit of exploration to read. For example, I need to transit the entire list of 1 2 3 4 to understand all that is being added, which can be more difficult with longer expressions. But that can be mitigated with formatting:

  (+ (this that)
     (func zzz)
     (if (< v q) 1 3))

(Function conditions are also fun to intermix into things!)

I think just as a rule, I find formatting more important in general with s-expr systems than algolesque systems.

> If I have to write 1 + 2 * 5 - 3

That's a great example of an expression that can be ambiguous, but not with prefix/suffix notation.

Most people that write lisp-like code use an editor that helps with s-exp editing (like paredit), so that isn't really a significant issue. In fact, I think it is faster to write s-exp code than algol-likes once you've become accustomed.

I agree that formatting is very important w/ parens langs, but there are many languages that consider formatting a high concern.

I would also argue that reading code is harder than writing it. Optimizations that speed up writing code is less interesting to me than ones the help reading/understanding/making assertions easier about code.

Finally, infix notation is available in lisp/scheme, it's just a macro away (but seriously, don't).

I find value in ease of "local" modifications to code. My editor being able to indent as soon as I type or paste code is a huge time saver. What's an even bigger time saver is my editor being able to perform tree operations on tree-like data.

When using "curly brace languages", what I really miss is structural editing. I often deal with tree-like structures in any language, and being unable to simply cut a node, move my cursor to the start/end of a node, nest something, etc. is really inconvenient. These are operations that take me at most a second when using Emacs with smartparens. In JSX, for example, these one-second operations need me to imitate smartparens' behavior by hand then run Prettier since indenting by hand is an even bigger waste of time. Transforming e.g.

  <Foo>
    <Bar>
      <Baz />
    </Bar>
  </Foo>

  <Foo>
    <Bar />
    <Baz />
  </Foo>

takes *seconds* even though the equivalent operation with S-expressions is a single keybind in Emacs.

Where this happy infix world goes wrong is precedence rules, especially where they're different between different languages.

The numerical operators, with the Boolean operators, negation, comparisons, maybe implicit type conversions as well. Maybe && as separate from &. Maybe user defined operators with different precedence to the builtin ones.

Maybe the large precedence table you have to keep in working memory to use the infix conventions is still simpler. Maybe even when there's a style guide saying to put lots of parentheses in as well. It starts to be difficult to fit a definition of simple to the observations though.

> My problem with prefix, is simply that my mind does not think in prefix.

Mine, neither, for maths.

But for everything else, we’re both already used to prefix:

    fprintf(STDOUT, "foo %d", 3);

is prefix, just as much as this is:

    (format *standard-output* "foo ~d" 3)

And it turns out that the advantages of a single homoiconic notation are so compelling that it’s worth a little bit of mild ugliness when dealing with maths.

I prefer [1,2,3,4].sum that you can get in ruby out of the box, but `1 2 3 4 sum` would look great too.

Now if we want to handle compounded expression, you need either a given constant finite number of argument, or have a reserved word to mark grouping, much like `)`. A bit like stack based programming languages.

That's the usual issue, people want their language to be a glorified pocket calculator, so they can type their usual formulas as-is, while lisp rapidly grew a culture of searching for new and larger abstractions. I know some people who would die writing an imperative for loop over an external accumulator rather than (+ nums...) of (fold, +, nums).

I keep trying to pin point the psychology of it. Cause even as a kid, I was more attracted toward HP calcs even though I never heard of lisp at this point, but RPL felt like infinite magic. And of course when I ran into emacs, I felt the same strange feeling.. there's something.

FORTH go PROSPER and

Method calls are infix:

    target.method(argument, another)

Here, the operation is `method` and the operands are `target`, `argument`, and `another. Note that the operation appears in the middle of the operands.

Fair point. I was considering `target.method` as the operator.

It depends on the language's semantics. Sometimes (as in Python), `target.method(a, b)` really is two separate operations, `target.method` (which returns a bound function) and then `<thing>(a, b)` which applies arguments to the result.

Even then, it's still not a prefix operation. It's postfix.

Whew. (Wipes sweat off brow).

Things like this are mentioned, in some detail, in the O'Reilly book Python in a Nutshell, IIRC, in the first edition, which is what I have.

Couldn't quite wrap my head around all the material in that chapter, TBH.

But I still like to read about such stuff, and I do understand bits and pieces of it.

In Python, the "." in "target . method" is an infix operator.

Note that the "(" in (a, b) is also an operator. (There is some special parsing because otherwise you could do things like args = (1, 2, b=3); target.method args.)

As to whether <thing from target.method><thing from (a, b)> is postfix, I'm not sure how you get there. Yes, there's an implicit funcall at the end, but there's something similar with (+ a b) or ((. target method) (arglist a b)) and we wouldn't call them postfix.

You're right. Function application is essentially an infix `(` operator. Not sure how I got that wrong.

Not really because the ordering is unambiguous given the parens. No need for operator precedence rules like PEMDAS.

Oh, you still have to worry about precedence. Consider:

    var x = 123
    print(-x.abs())

Or even:

    print(-123.abs())

What do those print? Do they print the same thing?

Unary operators are still operators. The integer parsing rules are probably different. In Lisp, -x would be a symbol, and the proper analog to -123 would be (- x) eg.

I think we're in agreement. `-` and `.` are both operators and the language and user have to understand the relative precedence of them.

> The only thing that makes Lisp unique in this context is that it also makes arithmetic operations prefix

I think that most problematic for prefix notation are not arithmetic operations, but field accessors.

In C you have a->b->c->d, in Lisp it would be (d (c (b a))), which makes you to jump to the center and read it from the inside-out.

In Lisp one could have (-> a b c d), just like (+ (+ 2 3) 4) is (+ 2 3 4).

The direct translation of the C expression to Lisp would actually be (-> a (-> b (-> c d))), which is fine to read from left to right as well. As lispm said, this can be reduced to (-> a b c d) due to the flexibility of prefix operations.

The direct translation of the Lisp expression you shared to C would be: d(c(b(a))), which just like the Lisp expression, evaluates from the middle out. Both are fine to read from left to right though.

> The direct translation of the C expression to Lisp would actually be (-> a (-> b (-> c d)))

Not really. -> looks like binary infix operator, but it is really an unary postfix operator (parametrized by field). Because field itself is not a first-class entity in C.

Either -> is a binary operator or is is not an operator in the expression at all, and the unary postfix operators are ->b, ->c, and ->d. In the latter case, that gives us (->d (->c (->b a))) in Lisp, which I can see how ypu could get, but I don't agree.

    #include <stdio.h>
    #include <stdlib.h>

    struct foo {
      int a;
    };

    int main() {
      struct foo *f = malloc(sizeof(struct foo));
      f->a = 5;
      printf("%d\n", f->b);
      free(f);
      return 0;
    }


    test.c:11:21: error: no member named 'b' in 'struct foo'
       11 |   printf("%d\n", f->b);
          |                  ~  ^
    1 error generated.

What do you mean when you say fields are not first class in C?

> Most operations in most languages use prefix notation

Yeah, and IMHO most operations in most languages suffer from being mostly prefix. Yes, LISP is not that much worse, but doubling down on the bad part doesn't exactly recommend it. ¯\_(ツ)_/¯

One of the cool things about Smalltalk is that it consistently makes everything infix.

Reply on news.ycombinator.com