KSP-KOS / KOS

Fully programmable autopilot mod for KSP. Originally By Nivekk
Other
691 stars 229 forks source link

[proposal] functions as callbacks #740

Closed abenkovskii closed 8 years ago

abenkovskii commented 9 years ago

see this wiki page Not in next update but at some point you might want to introduce callbacks. How I would like to see it:

declare function foo  // declare a library function
{
  declare parameter callback.
  print callback(42).
}
declare function bar  // declare a callback
{
  declare parameter x.
  return x*x - x.
}
foo(bar). // pass the callback into library function as parameter

The current implementation of functions will think that foo(bar). is foo(bar()). But considering bar and bar() the same prevents you from introducing callbacks later (or at least you will have to add some complex syntax like foo(bar as callback)). May be it is not to late to make parentheses required?

Dunbaratu commented 9 years ago

The things you bring up are things we've thought of before and I've had in the back of my mind.

The original reason for making parens optional is that we re-worked a lot of the old suffixes into new suffix-mehods and decided at that point that making the parens optional allowed that to be done in a way the users never notice. They can keep using the suffix the way they had been.

There is precedent to making a callback use funky syntax. C's function pointers did this.

I'd prefer it actually. While languages traditionally have made callback syntax be "leave the parens off" I never really liked that. I don't think it's stated obviously enough that "I'm not really calling this right now".

I was thinking of something like: ^bar or a similar punctuation would be nice, but not particularly in keeping with how kerboscript looks. Kerboscript tends to spell things out with words, so it would probably be something like delegate bar or callback bar.

abenkovskii commented 9 years ago
  1. I personally like a Pythons approach where type, class, method, function and so on are just types of values. Imagine a list of callbacks, callbacks as return values. In Python function isn't something special and follows the same rules as other variables.
  2. Newer heard about a language where leaving the parentheses off is a syntax to call the function (except kerboscript). But it looks like you coded a lot on this language.
Dunbaratu commented 9 years ago

I personally like a Pythons approach where type, class, method, function and so on are just types of values.

This is still a proposal that a callback is a type of value. I'm just talking about the syntax for specifying that you're not trying to call the function at the moment.

For example, when I proposed callback bar, I was picturing being able to use it like so:

set comparator to callback myGreaterThan.
mylist:sort(comparator).

as an example. You can still store a callback foo in some variable in what I was proposing.

Newer heard about a language where leaving the parentheses off is a syntax to call the function (except kerboscript). But it looks like you coded a lot on this language.

There are things in Kerboscript that are weird for backward compatibility reasons. It's not the language design I'd have gone with if I was doing it from scratch myself. I'm just trying to find ways to extend it without breaking it too much. To understand the history of why we allow parens to be left off: originally there was no such thing as a suffix that accepted arguments. We added that. Previously ALL suffixes had no parens, even the ones that "did something".

tomekpiotrowski commented 9 years ago

Is anyone working on this? I find the lack of this feature really irritating as it prevents me from implementing more flexible scripts.

I might have some time in the coming weeks, if someone could outline what needs to be done here in a bit more detail maybe I could work on it.

Dunbaratu commented 9 years ago

I think it's not on anyone's near future list. Too many other things to work on first. If you want to give this a shot, keep in mind that a future design goal for kOS is to eventually have a kOS-defined wrapper class around ALL types that a kOS script can get into a variable. Thus don't just return a native C# delegate in the user's variable, but instead make some kind of a KOSDelegate wrapper type and return that.

tomekpiotrowski commented 8 years ago

Fixed in #1315