Lambda the Ultimate

Interesting point, that approach is at both ends of the spectrum between 2 and 3.

Although Lisp also applies tighter binding for backquotes, and creates right-deep ASTs for implicit sequences of applications of cons when lists are formed by juxtaposition and don't explicitly (edit: i had said implicitly) mention the . operator. (I'm not a Lisp language lawyer, this is just my understanding from a course a few years back. I could be either entirely wrong or wrong on some technicality here.)

always groups operators to the less

The expression 2 + 3 * 5 is 25 in Smalltalk, not 17 as it would be in C or Java.

I would argue that Smalltalk doesn't have operators. The above expression means "Send the message '+' with one parameter '3' to the object '2'; then send the message '*' with one parameter '5' to the result."

That's actually another way of dealing with operator precedence: denial. Without operators there's no operator precedence.

The same could be said about Haskell: x + y means calling the function + on x and y. But there is a difference between regular functions and operators: the syntax.

In Scala, like Smalltalk, 3 + 2 is sending a + message to a 3 object. In .() notation, it's the equivalent of 3.+(2). And + is an ordinary method name - you're free to name your own methods +.

Nonetheless, Scala has precedence for messages that are named as "operators". 2 + 3 * 7 = 23 translates to 2.+(3.*(7)).

While I'm at it, messages that end with : are messages sent to the argument on the right. For instance, List has a :: method, which in good functional tradition is pronounced "cons." Because of the right fix rule, 1::2::3::Nil translates to Nil.::(3).::(2).::(1).

There are even ways to create some unary methods so that !a is just a message sent to a.

It's not quite as flexible as Haskell which allows you to specify your own precedence and fixity, but it's pretty nice and illustrates another way a language can have precedence without really having operators.

I knew there was a reason I should stop using xml-schema all the time and learn a few more of these document structure languages.

Interesting example of #3, as opposed to the #1 choice made by a bunch of regular expression dialects (among them Posix and Perl) in essentially the same problem space. The RELAX NG grammar uses the same approach I had in mind, so that is comforting that I'm not totally off-base.

The language/method I developed does it this way. There is default precedence but you can modify it. Let me know if you're interested in looking at it.

The Fortress partial order approach is quite interesting (and seems also to be an example of the kind of extensibility--or at any rate potential for extensibility--mentioned above by Scott Johnson).

Extensibility is one of the major goals of Fortress. After all, it is designed by Guy "Growing a Language" Steele!

The idea is that Sun could never imagine all the possible uses of Fortress up front. And since the whole idea of Fortress is to provide computational scientists with a programming language that looks as much as possible like the LaTeX-typeset scientific papers or blackboard scribbles that they already write anyway, being able to adapt not only the APIs but also the operators and even the syntax to their specific scientific field is crucial. A geneticist, a quantum physicist and a fluid-dynamics expert would never be able to agree on one single syntax and one single set of operators with one single precedence table. And nor should they!

So, in Fortress being able to add and redefine operators, precedence and syntax, is crucial.

Good point about side effects. I hadn't been considering it because the language I was thinking about when I started the thread doesn't have expressions with side effects.

has little to do with operators per se--function calls suffer from the same problem.

The behavior of the following code

int subtract (int a, int b) { 
    return a - b; }

int main ()
{
    int x = 0;
    int y = subtract (++x, x++);
    printf ("The answer is %d\n", y);
    return 0;
}

is also not well-defined for the standard. The issue is that the arguments to a function, while strict, may be evaluated any any order the implementation chooses. If the leftmust argument is evaluated first, you get zero; if the rightmost argument is evaluated first, you get two. Most implementations I'm familiar with are left-to-right, but portable code cannot depend on that.

subtract(++x, x++) gives undefined behavior in C, meaning that there is no guarantee what it will do - akin to an unbounded error in Ada. Modifying a variable twice with no intervening sequencing isn't allowed. It's not just that either order may be chosen: an implementation might do both operations concurrently and lock up a platform that detects conflicting writes/race conditions, or its optimizer might decide to remove the code completely as it could never be called by a valid program.

Which is rather unrelated to the discussion on precedence, except to show that there's more to specifying evaluation sequence than just precedence. As concurrency continues to get more press, *not* constraining evaluation order unnecessarily might get to be more important.

I mean, seriously. Wow.

Where aren't the nasal demons lurking in C?

IIUC one of the advantages of using an operational semantics to define R6RS Scheme was that it made it easier (possible?) to formally specify that the evaluation order of arguments to a function is undefined. I personally find this to be a perfectly reasonable position to take. If you are going to make that requirement for an M-expression(ish) language like C, doesn't it make sense to extend it to infix operator application as well?

in Lisp, they are obligatory (for other reasons)

Well, indeed - just to belabor the point, in lisp, parens aren't even for precedence particularly, they're just denoting cons-list/tree structure (which is then (maybe) evaluated*). (1+1) == 1+1 in maths, but '(hello) != 'hello in lisp.

* yielding another "false friend" that lisp parens are a bit like the func(blah, baz) parens in C, only on the other side of the func and without commas (func blah baz). That's the apparent result, sure, but only because the lisp eval is defined, when it gets the list (func blah baz) to evaluate it by calling the function bound to func with the values bound to blah and baz.