2 ms·

It's a clever design, and Wheeler makes a good case for it. Certainly my first reaction is "you'll have to pry my parentheses from my cold, dead fingers", but

It's a clever design, and Wheeler makes a good case for it. Certainly my first reaction is "you'll have to pry my parentheses from my cold, dead fingers", but it's unarguable that a lot of people are repulsed by the syntax, even if the enlightened among us know it's actually beautiful. He's right about the requirements for such a syntax: it has to mix well with the existing syntax, meaning, among other things, it must impose no semantics and it must not be necessary to write the operands of an infix expression in infix. I don't recall CGOL etc. getting the latter right. I also agree with him about the lack of a precedence scheme. I have to admit, I can see making light use of the curly infix syntax in my own programs. I'm less sure what I think about the modern-expressions; I'd have to try them to see. I guess I can see some advantages. But I'm afraid I draw the line at significant whitespace. I know it works for Python, but Python was designed for it from the ground up. Looking at Wheeler's example, I'm not persuaded that it works as well for Lisp, though I commend him for his effort in designing it.

ScottBurson 16y ago
Having the infix expression reader fall back to emitting calls to a user-provided `nfx' macro seems clever at first glance, but it's insufficient. Different programs/libraries are likely to likely to implement `nfx' in different ways, and thus step on each other. I think (for Common Lisp) it will be necessary to do something like this: create a generic function `translate-nfx' which uses `eql' dispatching on the first operator, and set up the `nfx' macro to call it: (defmacro nfx (&rest stuff) (translate-nfx (cadr stuff) stuff)) (defmethod translate-nfx ((op (eql '+)) stuff) ...) This creates an extensible framework where packages can supply `translate-nfx' methods for their operations. It would probably be worth predefining methods for CL arithmetic operations, so that users don't wind up doing that in incompatible ways. I'm afraid that means choosing a precedence scheme, which Wheeler was trying to avoid (for good reason); I don't see a way around it, though.

ScottBurson 16y ago

Having the infix expression reader fall back to emitting calls to a user-provided `nfx' macro seems clever at first glance, but it's insufficient. Different programs/libraries are likely to likely to implement `nfx' in different ways, and thus step on each other. I think (for Common Lisp) it will be necessary to do something like this: create a generic function `translate-nfx' which uses `eql' dispatching on the first operator, and set up the `nfx' macro to call it: (defmacro nfx (&rest stuff) (translate-nfx (cadr stuff) stuff)) (defmethod translate-nfx ((op (eql '+)) stuff) ...) This creates an extensible framework where packages can supply `translate-nfx' methods for their operations. It would probably be worth predefining methods for CL arithmetic operations, so that users don't wind up doing that in incompatible ways. I'm afraid that means choosing a precedence scheme, which Wheeler was trying to avoid (for good reason); I don't see a way around it, though.