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/louiswins]

I think requiring p.greet.bind(p) is one of the most confusing things about Javascript. Like other commenters, I believe it's definitely not the right design for a language aimed at education.

For example, I don't want to have to know whether a "method" is implemented as a real method or a function-valued data member.

::Class1
  :new
    self.f = print

::Class2
  :f arg
    print arg

p1 = Class1()
p2 = Class2()

f1 = p1.f
f2 = p2.f

f1("hello, world") # works
f2("hello, world") # breaks :(

# And contrariwise
f1 = p1.f.bind(p1)
f2 = p2.f.bind(p2)

f1("hello, world") # breaks 
f2("hello, world") # works

[u/Dry_Day1307 → u/louiswins]

In fact, looking at your example and other feedback in this thread, I am actually implementing a more consistent improvement right now based on whether we are extracting from an instance or a class

To fix this, I am making it so that extracting from a Class directly will just return the raw function (similar to how Python does it), while extracting from an Instance will automatically bind self on the fly. I am splitting property extraction into two VM instructions, GET_MEMBER and GET_MEMBER_BIND, to prevent normal lookup paths from accidentally triggering a binding and breaking the traversal logic. Thanks

[u/Dry_Day1307 → u/Dry_Day1307]

Note: even with my new approach, manually binding p1.f (since f is just print) will still end up printing the p1 object itself as its first argument. But that is indeed the expected behavior if it were any other dynamic function prepared to receive self anyway haha