[RFC] Object method message passing syntax

[mhermier]

Hi,
One of the last features that retains me from updating #1006, is that I lack a way to implement method invocation. While ideally it should look like:

some_method_mirror.call(receiver, args)

there are some technical issues that forbid to do that in a module (basically I need at minimum a primitive or language support). And that issue makes me struggling since a while.

One idea that came to my mind (after viewing a video about OOP today), would be to add language support for that feature.

I think about 2 ideas for the syntax:

var symbol="call(_,_)"

// @ is a placeholder token, but I like it or maybe `@@`
receiver@("call()")
receiver@(symbol, arg0, arg1)
// or
receiver."call()"(args0, arg1)
receiver."%(symbol)"(args0, arg1)

Implementation wise, it would more sense to have the symbol string as the last parameter. So the opcode would not need to shift all the arguments on the stack after resolving the symbol index. But these syntax feels quite natural.

With the first syntax, since the symbol is evaluated as a regular value, it must be inside the parenthesis to avoid parsing hell problems with mixed getter/setter syntax shown in the following example:

receiver@foo.getMirror().toString(arg0, arg1) // That cannot be parsed
receiver@(foo.getMirror().toString, arg0, arg1) // Parse nicely

The second syntax has the advantage of not consuming a token for that feature. But cost the allocation of a string in what I consider it the more general usage. edit Thinking at it again the syntax is viable, by optimizing the string interpolation implementation and String.+(_) (which are really under optimized right now...)

edit: It should help to solve a not solvable problem of the constructor syntax. Because of the way constructors are implemented, you can't call a constructor named differently. With super, we end up having chains of construct new which defeat the point of having named constructor. It is a secondary usage that I would not recommend, and use super where possible, but it at least gives a solution to that problem.

[PureFox48]

If we need language support for this then, to my mind, the nicer syntax of the two would be:

receiver@(symbol, arg0, arg1)

If #1154 lands, then @ would already be an available token in the language. I see no particular reason to double it even if the receiver were a class rather than an instance thereof.

Although I note what you say about having the symbol string as the last parameter, placing it first seems more natural to me.

[mhermier]

If #1161 lands, second syntax will become viable. It would only cost a ".toString" call which should not allocate in the general case. So it is an overhead I'm willing to pay

[mhermier]

Added a commend about how it can help with the constructor of different name issue.

[PureFox48]

Yes, that's a point worth making as the current situation of not being able to directly call a parent constructor with a different name using super is unsatisfactory.

Another thing I noticed recently is that one can have both a constructor and a static method with the same signature - apparently the last one to be declared always wins!

[mhermier]

This is by design, and is one of the things I really don't like. It defeat the point of named constructors in some way...

class Foo {
  construct foo() {} // That creates `static foo()` and  `"init foo()" so that it is not accessible by normal means
}

So what you are probably trying to do is:

class Foo {
  construct foo(...) { foo(...) }
  foo(...)
}

[PureFox48]

There's actually a fix for it, namely #820, which is how I came to notice it in the first place.

Not sure why this wasn't merged into Wren 0.4.0 unless there's some problem with it.

[mhermier]

For me that behavior is broken. It would make more sense to have them as a regular function. It would be callable from constructor by normal mean, and would allow to create some constructors and modifiers in one go.

[mhermier]

I implemented the obj."method"(args) syntax, so far it works great. I still have to implement super."method"(args).

Thought there is something that I don't really like.

class Foo {
  static foo() { "bar()"() }
  static bar() { }
}

This should technically be valid, but it is too much complicated for the compiler, because of string interpolation.

Using the @ syntax allow to solve this, but I'm not pleased to have @ as binary left and unary operator implicit this.

class Foo {
  static foo() {
    @("bar()") // This feels more awkward to me than
    ."bar()"() // that
  }
  static bar() { }
}

I'll probably will not bother for wren, and only allow them with an explicit receiver.
But this is an extra argument for me to have . unary operator as implicit this in veery...

[PureFox48]

Why don't you just specify that if the "bar()" syntax is used (or the @ syntax for that matter), then there must be an explicit receiver even if it's just this.

If nothing else, that will prevent people from mixing it up with ordinary strings.

[mhermier]

For wren, I'll remain simple and impose explicit receiver.

The thing is that, by allowing the obj."method"(arg) syntax, it blurs the differences between a method name and a string. So it is reasonable to assume we can use that syntax in the other contexts, like the implicit this method call. Strictly speaking, unless I missed something, nothing prevent from adding this rule in the grammar (only the compiler do). But I found its interaction with name resolution to be disturbing (for the human eye), and it makes me reconsider the old idea of the unary left .. Visually, we see it is an implicit this call. In the normal case .call(), it allow the compiler to avoid round trips in name resolution, since that syntax makes the identifier an explicit method name.

[mhermier]

I just thought about another syntax that is a mix of both:

receiver.@"method"(args)
@"method"(args) // implicit this

More interesting?

[PureFox48]

I hadn't really thought it through before but if "method" could be a variable (m say) rather than a string lteral, then you're going to need syntax such as receiver.@"method"(args) for disambiguation purposes.

This is because if people could write receiver.m(args) then it might mean they were calling a method m in receiver's class which would therefore be ambiguous. Having to write receiver.@m(args) would remove the ambiguity.

@"method"(args) or @m(args) would also then be fine as the implicit receiver could be nothing other than this.

[mhermier]

True, and interesting. Thought it would mean the support for full fledged expression would need to be added. So
receiver.@(expr.to.method)(args) would make sense, and the presence of extra '()' is an extra debate.
Yet, I would rely on string interpolation to provide some security and simplicity.

[PureFox48]

Yeah, logically the method signature would have to be an arbitrary expression which evaluated to a string.

It starts to get a bit complicated though as you could have function calls and all sorts of stuff in that expression. Having said that, even if you restricted it to string literals you could still have arbitrary interpolated expressions within that!

As long as it's manageable, perhaps this sort of complication isn't a bad thing as it gives folks more freedom to define the method signature. However from an aesthetic viewpoint it's not so nice.

One thing you could do would be to restrict the expression following @ to being a simple variable. However, if you did that, then folks would need to assign the method signature expression to the variable before they could call the method so it would always be a two-stage process.

[mhermier]

If we take the simple example of the visitor pattern, it make the thing a little bit more simple. The visitor can directly dispatch, enforcing some method name convention. Like `visitor@"visit%(receiver.type)"(receiver)`. It is a double edge sword, since there is a direct correlation between the method name and type, but it is good for the simplicity it brings.