Alternative syntax for method calls - changes foo#bar to foo..bar.

[SanderSpies]

Fixes #523

Also related to #366

[jordwalke]

I'd like to hear what others think of this.

[tadeuzagallo]

I'm new here, and to OCaml, but this seems very counter intuitive to me. I'd expect it to be a range, but not a method call. I think I might have seen someone suggesting ::, imho that'd be a better option.

[SanderSpies]

@tadeuzagallo Agree that it looks like a range, however using :: makes it look like a list.

[tadeuzagallo]

@SanderSpies Oh, didn't think about it... but still, between the two, I like :: better.

[yunxing]

@SanderSpies Thanks for implementing this. foo..bar actually looks confusing to me (more like a range as suppose to method selection). Maybe -> looks better?

[SanderSpies]

@yunxing looks good to me.

@tadeuzagallo what do you think?

[braibant]

I am following activity on reason and see many proposals for syntax changes that are "local" (in the sense that they consider one syntactic construction at a time). Yet, those changes have ramifications on other changes (e.g., this one on #581, #523).

reason has some traction, and it would be nice not to confuse people more by making changes to the syntax that turn out to be blocking for something else. Would it make sense to discuss changes to the syntax more globally, through appropriate channels (for instance, using a single issue, rather than many different ones)?

Also, as I pointed out in #557 (and was pointed out independently in #568), it would be nice if the changes in the reason syntax did not make the code not-understandable by people accustomed to the OCaml syntax (or less compatible in a sense).

[jordwalke]

One thought: if :: looks like a list, then named arguments already have that problem! However, :: only resembles a list to people who use OCaml daily.

@braibant : Many of these proposed changes are just pull requests, many of them don't arise from any official discussions - they're just people getting their ideas out there in the best possible way - code. We welcome pull requests, even if they're silly or just a means of learning. When syntactic changes like this are very local, and have ramifications to the wider syntactic real estate, that will come up in discussion on the diff and it's a really great way for people to learn. So I'd say we can take individual, smaller PRs with a grain of salt and people who send them understand this as well. Then, in addition to that, as you suggested, we should have larger, more holistic conversations for big topics such as "named arguments" (you can see we have existing threads for those which cover a ton of edge cases and considers how it effects the entire grammar).

I am curious about one comment you made - that making the syntax immediately recognizable to OCaml programmers should be a goal. I agree it would be nice, but surely that comes at the cost of making it more difficult to recognize for non-OCaml programmers. If we have to choose one of those audiences to cater to, which one do you suggest and why? A few things to consider:

1. There are 99 non-OCaml programmers for every 1 OCaml programmer.
2. OCaml programmers eat new programming languages for breakfast and can learn them very quickly - many OCaml programmers use OCaml to implement new languages.
3. OCaml programmers already have a syntax that they love, correct?

[bsansouci]

What about ->? It might look like a pointer dereferencing for low level folks, but at least myObj->method1->method2 won't look too out of place. OCaml folks might hate it though because it looks like a type declaration :/

Actually this myObject$mymethod1 doesn't seem too bad either. Chaining a bunch is hard to read though: myObject$mymethod1$mymethod2...

Edit: what about / so myObject/myMethod arg1 arg2. Almost looks like some clojure namespace?

[jordwalke]

Thanks for the ideas, @bsansouci!

Another extreme idea I had thrown around earlier was that records would look more like variants, in that they have all leading capital letters. It makes sense when pattern matching or creating variants with records inside - capitals become the visual language for "pattern matchable thing":

let somePoint = Some {X: 0, Y: 100};
let res = switch {
  | None => 0
  | Some p => p.X + p.Y
};

/*
 * This is actually an object, not a record.
 */
let myObject = {
   myMethod: fun a b => a + b,
   private myPrivateMethod: fun a b => a + b
};
let result = myObject.myMethod 10 20;
let result = myObject.myPrivateMethod 10 20;

I decided against it because records are faster than objects (a better default) and it makes punning weird (X is punned to x). Instead, I leaned more towards coming up with a proposal for minimally extensible records that would retain performance, but satisfy many of the use cases for objects, and then I'd be less concerned with how ugly objects were.

Just my current thoughts, that I'm totally flexible on.