I disagree. x.y should remain (x y). It's plain confusing if you make it look like the dot notation in "object-oriented" languages, when it clearly is not. It's just an alternative way to write function application!
It would make more sense to provide the following kind of implicit currying:
Besides, if you switched the arguments or otherwise limited the usefulness of the new syntax to "(obj.f x1 x2)", you could never chain as in "f.obj.x1.x2"; instead, you would need to write "x2.x1.obj.f", which looks ridiculous.
I'm in favour of the dot syntax as infix function application operator. It reminds me of Edsger Dijkstra's reasoning (in fact, he also used the dot as function application). You may want to read [1] for the full story and other nice pondering about infix operators and syntax.
Then what about "$"? Haskell uses "$" for infix function application operator. Composing objects and methods with "." or "->" is almost a de-facto standard that too many people have got used to...
The dot notation is used for at least two different purposes: accessing field values (C structures, for example) and calling methods on/sending messages to an object (Java, for example). Similarly the arrow notation is used for at least two different purposes: accessing field values through a pointer (pointers to C structures, for example) and calling methods on/sending messages to an object (Perl, for example).
Standard? I don't think so. They are used for very different purposes, and just because the convention of separating a record or an object and its attribute with a dot or an arrow is common is not reason enough to blindly adopt the same convention in a new programming language.
Does the dot notation as a record and field separator make sense? Maybe, if that's all you can do in your programming language. Take a look at Common Lisp defstruct for an example of another way to define structures and access fields.
