Iron out semantics of new object definition parameters and fields

[LPTK]

• [x] Do not generate accessors for let bindings (unlike val fields)
• [x] Only generate accessors for parameters marked val
• [x] Figure out whether we really should insert this implicitly when accessing members defined in the same scope. Currently we do it for members but not for parameters. We need something consistent and not too surprising.

Definitions:

Implicit this insertion: Accesses to members in scope are implicitly prefixed with this. in JS Direct member access: Accesses to members in scope refer to the specific member definition does not virtually dispatch to possibly overridden ones. This might be a bit annoying to implement for methods.

Currently, we use direct access for parameters, which is (currently) not very consistent but has advantages:

• It allows referring to these in the class ctor (where access to this should be forbidden for safety). Note that the ctor includes the initializers of all class fields. Making ctor semantics different from method body semantics is possible but would be surprising.
• Consistent with parameters that do not generate an accessor. And it would be strange if adding val to make the parameter generate an accessor would change the semantics of references to this parameter.

Pros of direct accesses for methods and fields:

• Allows using them in the ctor – currently one would need to use a let binding instead.
• Allows naturally defining efficient recursive functions, and converting tail-recursive ones to loops (this insertion would make these calls virtual)

Cons of direct accesses for methods:

• It doesn't match what happens in most Java-style language, which, unlike JS, allow omitting this.

[LPTK]

• [x] Note: the current semantics of val/fun implicit this insertion is inconsistent. It is performed for abstract class C { val x = 1; fun f = x } whereas abstract class C { val x : int; fun f = x } fails with "Code generation encountered an error: unresolved symbol x". The second one should work as well.

[LPTK]

After some consideration, I figured the best approach may be to:

• require the use of a virtual keyword for members that may be overridden later; and
• reject unqualified (i.e., this-less) accesses to virtual members.

This has lots of benefits:

• All accesses to non-virtual members in scope can be unqualified, and treated as though they were just variables in scope, which is morally fine because their targets won't unexpectedly be rewired by derived classes, helping to reason about semantics.
• When they are not virtual, which will be most of the time, val members, fun members, val parameters, and non-val parameters can all be safely accessed without qualification uniformly in any place of the class, including in the constructor, and their semantic is obvious and unsurprising, unlike in Scala (1).
• In valid code, virtual dispatch/open recursion is always clearly indicated by the this. prefix (it won't happen implicitly by just referring to a plain identifier).
• The fact that virtual members can't be accessed in the constructor becomes an obvious consequence of this not being available in constructors.
• Unlike approaches allowing direct/bypass access to the possibly-overridden implementations of virtual members, this approach won't be confusing to people coming from Java-like languages (i.e., no unexpected direct accesses to virtual members).
• Methods are not openly-recursive by default, which more often matches the programmer's intuition and allows more consistent tail-call elimination by the compiler.
• In addition to all this, virtuality should arguably be opt-in anyway, like in C#, because it requires forethought from the programmer. Otherwise, downstream code is exposed to breakage induced by base changes from programmers not foreseeing these extensions, i.e., the "brittle base class" problem. Furthermore, we are already working on alternative modularity primitives (mixin families) which are better suited for software-product-line-style development than classical Java-style overriding anyway.

I expect virtual members to be the exception rather than the rules; therefore, the limitations attached to them are a fair price to pay for all these benefits.

---

(1) Consider how Scala is affected by potential initialization problems/footguns due to implicit virtuality by default (unless one uses the new initialization checker, which itself adds complexity and mental burden):

abstract class Foo { val x: Int; def foo = x }
object Bar extends Foo { val x = foo }
Bar.x // 0 (!!! uninitialized !!!)

class A { val x = 1; val y = x + 1; def z = x + 1 }
object B extends A { override val x = 2 }
B.y // 1 (!!! value was set from uninitialized access to x, yielding 0 !!!)
B.z // 3

[LPTK]

Addressed in https://github.com/hkust-taco/mlscript/pull/175.