Operator overloading about koto

[irh]

On the other side, user-defined operators would be specific to libraries, so they wouldn't touch the language itself outside the scope of a particular library usage and that could be useful for some cases.

Yes I can see that point, but there is also a complexity cost in adding support for them in the parser, compiler, and runtime. It's not just the language that I want to keep small(ish) but also the implementation (although I'm not sure how much I've succeeded there! Always room for improvement..).

Like I say I'm not totally against it but I'd have to see a really convincing use-case, and yeah let's see where things are at once operator overloading is in place.

[irh]

Hi @ales-tsurko 👋

Your project sounds great, scripting an audio engine was one of the first motivations I had when I started on Koto. I'd be really happy to see this happen.

I think it's very suitable for live coding and programming newcomers.

This is exactly what I'm aiming for so that's great to hear =) When you find parts of the language that go against these goals please let me know.

What's your plans on koto?

Things have slowed down a bit for Koto since I became a Dad, but it's still important to me that the project continues so my intention for this year is to spend roughly one day per week pushing it forward. I'd be very happy if people start contributing to speed things up a bit, but for that to happen I need to spend some time on documentation, make it easier for people to find their way around the code, log some 'good first issue' issues, etc.

I see a branch for operator overloading, but it looks like you switched to other tasks. Do you have any plans to finish it and whether there's any estimation, when it will be ready if the answer is yes?

I would like to finish it, but I don't have an estimate for when it will happen. Mostly I've just been adding in features when I've needed them. I started exploring operator overloading while working through the Advent of Code puzzles and I thought I would need a 'big number' type, but in the end #23 was sufficient and I moved on. The fact that you're interested does make it more likely that it'll happen sooner though =)

I plan to take a different approach to how I started out on the branch: each Map will have something like a 'meta map' (similar in spirit to Lua's metatables) which will contain the overloaded functions, but could also contain other useful stuff later on like help strings.

I sketched out what I thought it could look like in use:

#@ This is the help string for make_foo
make_foo = |x| 
  #@ This is the help string for the x value
  x: x

  # Binary operators
  @add: |self, other| make_foo self.x + other.x
  @subtract: |self, other| make_foo self.x - other.x
  @multiply: |self, other| make_foo self.x * other.x
  @divide: |self, other| make_foo self.x / other.x
  @modulo: |self, other| make_foo self.x % other.x

  # Unary operators
  @negate: |self| make_foo -self.x

  # Comparison operators
  @less: |self, other| make_foo self.x < other.x
  @less_or_equal: |self, other| make_foo self.x <= other.x
  @greater: |self, other| make_foo self.x > other.x
  @greater_or_equal: |self, other| make_foo self.x >= other.x
  @equal: |self, other| self.x == other.x
  @not_equal: |self, other| !(self == other)

  # Indexing
  @index: |self, i| self.x + i

  # Language Extras
  @iterable: |self| 
    # Return an iterable (could be a generator)
    0..self.x 
  @debug: |self| 
    # Provide a string to be used in `debug` statements
    "{}".format self.x
  @type: || "Foo"

assert_eq ((make_foo 1) + (make_foo 2)), (make_foo 3)
assert_eq make_foo(5).to_tuple(), (0, 1, 2, 3, 4)

There will be some details to figure out but this is the direction I have in mind.

What would you like to see happen with operator overloading? Do you think this would cover your needs?

[ales-tsurko]

Your project sounds great, scripting an audio engine was one of the first motivations I had when I started on Koto. I'd be really happy to see this happen.

This is exactly what I'm aiming for so that's great to hear =) When you find parts of the language that go against these goals please let me know.

That's cool! Koto is exacly what I need for my project!

I like your approach on operator overloading. Speaking about my project, that would pass my needs partly. But there still are bitwise operations and maybe custom operators for which you should extend Koto on the rust side (or fork it?). So that would be great if it was possible to define operators per map. Maybe using the same syntax, but specifying operators literally? For example:

# ...
  @+: |self, other| make_foo self.x + other.x
  @-: |self, other| make_foo self.x - other.x
  @*: |self, other| make_foo self.x * other.x
  @&: |self, other| make_foo (bit_add self.x, other.x)
# ...

This is for binary operators only, though. There should be something for unary as well... And I'm not sure about indexing, for example... So maybe a better option would be extending the operator table, but having some defined operators there already?

operator_table.add "op_bit_and", "&", "binary" # name, token, type

# then define it per map as you suggested

# ...
  @op_bit_and: |self, other| make_foo (bit_and self.x, other.x)
# ...

There could be binary, unary and "indexing" types of operators for example. And that would be possible to extend types of operators in the table in the future. I understand that this is out of the operator overloading task, but I could help with this feature. I'm not familiar enough with the architecture and code base for now, though. Anyway, I'm ready to invest full-time into operator overloading/operator table as it's critical for my project and despite the direct contribution, the only options I have is either using functions instead of operators or fork/extend the language on the Rust side.

[irh]

I did think about unary operators and indexing but my example wasn't clear enough, I've edited the comment above to make them pop out a bit more.

But there still are bitwise operations

Yes, bitwise ops are a missing feature, and they make a lot more sense for Koto since #23 - you can go ahead and create a new issue if you like.

Anyway, I'm ready to invest full-time into operator overloading/operator table as it's critical for my project and despite the direct contribution,

That's great that you're up for contributing! Tell you what, I don't have time today, but I have some hours tomorrow and I could try to get things going. If I don't get it finished then at least you'll have a good starting point.

[irh]

maybe custom operators

I think I'm unlikely to want to add custom operators, my concern is that they would be too surprising and I'm trying to keep the language small and simple. I'm open to being convinced otherwise, but maybe the feature deserves a separate issue.

[ales-tsurko]

Tell you what, I don't have time today, but I have some hours tomorrow and I could try to get things going. If I don't get it finished then at least you'll have a good starting point.

Great! Meanwhile, I'll be getting familiar with the code base.

I think I'm unlikely to want to add custom operators, my concern is that they would be that they would be too surprising and I'm trying to keep the language small and simple. I'm open to being convinced otherwise, but maybe the feature deserves a separate issue.

They could be useful in live coding libraries, when you need very little typing. Especially for patterns. But I agree, it's introduce complexity making code less readable, moreover Koto is already syntactically short enough for stuff like that. On the other side, user-defined operators would be specific to libraries, so they wouldn't touch the language itself outside the scope of a particular library usage and that could be useful for some cases. But If there would already be operator overloading with all common operators, user-defined operators were a nice-to-have, but not much important.

[irh]

@ales-tsurko I had a bit of time over the weekend to get started on operator overloading, you can take a look at the branch operator-overloading-2. It's a bit tricky because now external (i.e. Rust) functions need to perform Value operations via the vm (e.g. you can't simply use Value's PartialOrd implementation). A custom implementation of sort on ValueList and ValueMap will be needed to take overloaded < operators into account (along with error propagation), and I haven't figured out if there's going to be a way to allow the overloaded == operator to be taken into account when storing Values as keys in ValueMaps (I doubt there is without a custom map type).

If you're interested in taking a look at moving it forward, go for it! Feel free to email me with questions. Otherwise I'll be able to make some more progress later in the week.

[ales-tsurko]

Cool! I'll take a look.