The doc for runtime.Call says:
func Call(t *Thread, f Value, args []Value, next Cont) error
Call calls f with arguments args, pushing the results on next. It may use the metamethod '__call' if f is not callable.
Actually, Call not only pushes the results of the call to f onto next, but proceeds running next and further continuations until nil or an error occurs.
I'm guessing this is the intended behavior, but I think that with this documentation and/or the name Call, this API is confusing, especially if seen in contrast to runtime.Call1, which has a more "expected" signature:
func Call1(t *Thread, f Value, args ...Value) (Value, error)
One possibility to make the API more intuitive would be to rename Call to something else (e. g. TailCall) and add a new Call API
func Call(t *Thread, f Value, args []Value, ret []Value) error
whose implementation would call the "old" Call with a termination for next.
What do you think?
The doc for
runtime.Callsays:Actually,
Callnot only pushes the results of the call tofontonext, but proceeds runningnextand further continuations untilnilor an error occurs.I'm guessing this is the intended behavior, but I think that with this documentation and/or the name
Call, this API is confusing, especially if seen in contrast toruntime.Call1, which has a more "expected" signature:One possibility to make the API more intuitive would be to rename
Callto something else (e. g.TailCall) and add a newCallAPIwhose implementation would call the "old"
Callwith a termination fornext.What do you think?