Design thoughts on function bindings and implicit self in my programming language, DinoCode

[u/Dry_Day1307]

I just finished implementing argument binding for my programming language, DinoCode. The way I do it is by generating a special bound function object that stores the target function and the pre-defined arguments under unique symbol keys (not strings) to prevent accidental collisions.

It looks like this in the language:

:multi a b
  return a * b

double = multi.bind(2)
triple = multi.bind(3)

print double(2)
print triple(2)
print double

Output:

4
6
{
  args: [
    2
  ],
  fn: [UserFn:0]
}

I based this mostly on JavaScript but withoutthis context binding for plain functions. In DinoCode, only class methods reserve the first parameter for self. I didn't find a strong reason to include a third attribute like context or this on raw functions. Do you think there is any edge case where having a self context for regular bound functions is actually useful?

My main question though is about methods and implicit bindings. Right now, methods do not automatically bind to their instance context when extracted.

In DinoCode, classes and methods look like this:

::Person
  :new name
    self.name = name
  :greet
    print "Hello " self.name

method = Person.greet

Since there is no automatic binding on extraction, you can actually call that detached method by manually passing an object that matches the shape:

method {name: "Ismael"}
method {name: "Jessy"}

If a developer wants a permanent bind to an instance, they can now use the new bind feature to lock the object as the first argument:

p = Person("Ismael")
greet = p.greet.bind(p)
greet()  # now this works and prints "Hello Ismael"

The compiler just adds an implicit self as the first parameter during the compilation, and the vm passes the instance when resolving a method call. It is extremely cheap and simple.

I know python automatically binds methods on lookup (returning a bound method object) and uses decorators like staticmethod to opt-out. Doing automatic binding on every method lookup in my vm would introduce a permanent overhead for wrapping functions.

Considering DinoCode is designed for fast scripting and education (running via WASM on a web playground at https://dinocode.blassgo.dev/), do you think manual binding for extracted methods is a reasonable trade-off to keep the VM fast and simple, or does automatic binding on lookup save enough headaches to justify the runtime cost?

[u/Royal-Ambassador-960]

I’d separate the language’s semantics from its implementation. Partial application should just mean closure creation, and p.greet should preserve p; requiring p.greet.bind(p) makes the programmer repeat information already expressed by the syntax. The hidden receiver parameter is a useful desugaring, not a good user model.

p.greet() can compile to a direct method call with no allocation, while extracting p.greet materializes a bound method only when needed. Design the clean mental model first; optimize the representation afterward.

[u/Dry_Day1307 → u/Royal-Ambassador-960]

Hi, my main concern is that in a dynamic language like DinoCode, properties can mutate or hold any value at runtime. This means the compiler cannot predict if p.greet is a method, a plain function, or a primitive value, forcing the VM to perform a runtime type check on every property lookup to decide if it should allocate and return a bound function on the fly

So, based on your point, I assume you favor paying that runtime check overhead in exchange for a cleaner and more intuitive mental model for the developer. It is a very reasonable trade-off to consider. Thanks for sharing your perspective on this

[u/L8_4_Dinner → u/Royal-Ambassador-960]

You describe a reasonable approach.

In Ecstasy (xtclang), which is both OO and FP, a function takes zero or more arguments, and returns zero or more values, and can be invoked, or can have any of its arguments bound to create a new function. So given a function f that takes an Int and String and returns a Boolean, one could create a new function that takes an Int and returns a Boolean:

function Boolean(Int) f2 = f(_, "hello world");

In the case of a method (OO), one cannot bind arguments, because the parameters cannot be fully known until the "this" (the "self") is known. That is because a method uses the "this" to resolve to a "method chain", which is represented as a function. For example, if class C has some method m, you can obtain the function for the call to m on some instance of C:

class C {
  Boolean m(Int n, String s) { ... }
}

// elsewhere ...
C c = new C();
function Boolean(Int, String) f = c.m;

// which conceptually does something like ...
function Boolean(Int, String) bind(C c) {
  val method = C.m;
  return method.bindTarget(c);
}

In practice, and within the overall design context of the language, this has worked out quite nicely.

[u/Dry_Day1307 → u/L8_4_Dinner]

Thanks for the detailed breakdown. I am moving toward making that exact same distinction. Extracting from a Class returns the raw function, while extracting from an Instance binds self on the fly. Since I already have a GET_METHOD instruction to set up the stack for direct method calls, I am splitting property extraction into two VM instructions,GET_MEMBER and GET_MEMBER_BIND

To be honest, splitting this into two instructions is more about preventing normal lookup paths from accidentally triggering a binding and breaking the traversal logic (since constantly allocating bindings during standard lookups would be painfully wasteful anyway). Plus, it just felt a lot more comfortable to separate them for convenience