Variable number of parameter support?

[waywardgeek]

How should Rune support variable number of parameters to a function?

The println/print discussion highlighted that Rune still does not support variable numbers of parameters. This makes it impossible to implement print in a library function. Python handles this nicely, with a trailing *args parameter, which get sa list of the remaining parameters.

For example, we could support something like:

class Foo(self, ...values) {
  self.values = values
}

foo = Foo(123, "test", [(1, 2)])
println foo.values
~               

If we just make a tuple out of the trailing parameters, it will create a new function for each way the function is called. This is just like C++ variadic function templates. The absl::PrintF template works this way.

In Rune, tuples can only be indexed by constants, not variables. So, this is not allowed:

t = (123, "test")
for i in range(t.length()) {
    print t[i]  // This is a compile-time error.
}

I'm not a big fan of C++ variadic templates. Recursive template programming seems to me like abuse of the type system.

What if we required the type of all the extra parameters to be the same? Then we could pass in an array, and the function could iterate through the array elements. However, we still couldn't implement print/println in a library.

[0dminnimda]

I think it's nice to have typed varadic arguments (it's fine to have more than one typed vararg per function), but yes, this does not solve the function-with-arbitrary-typed-vararg problem, aka the print function problem

And I guess that the answer to this question for any language that aims to be fast and compete with C is having an Any type and static reflection.
When compilation happens we know that here are only so many types - builtin ones and user-defined ones. Why not encode type information in global memory? Then we can have an Any type that will contain a pointer to the type and a void data pointer. Any can be casted to any type, but no operations can be done with it

Now implementation for varadics is more approachable - have an array of Any, iterate through it, check the type, cast it appropriately and do whatever you like!

In case of print one way is to generate a switch case for all types and call .toString() for each one
And another is to organise the type informaiton in such a way that function that make a string out of any type can be implemented - for example we toString(u32) as usual, but toString(class) would iterate through filelds and call toString on them

[waywardgeek]

Your proposal makes sense to me. We might put this off until the bootstrap, rewriting Rune in Rune, but something like this sounds good to me.

…

On Sat, Jan 7, 2023 at 5:12 PM 0dminnimda ***@***.***> wrote: I think it's nice to have typed varadic arguments (it's fine to have more than one typed vararg per function), but yes, this does not solve the function-with-arbitrary-typed-vararg problem, aka the print function problem And I guess that *the* answer to this question for any language that aims to be fast and compete with C is having an Any type and static reflection. When compilation happens we know that here are only so many types - builtin ones and user-defined ones. Why not encode type information in global memory? Then we can have an Any type that will contain a pointer to the type and a void data pointer. Any can be casted to any type, but no operations can be done with it Now implementation for varadics is more approachable - have an array of Any, iterate through it, check the type, cast it appropriately and do whatever you like! In case of print one way is to generate a switch case for all types and call .toString() for each one And another is to organise the type informaiton in such a way that function that make a string out of any type can be implemented - for example we toString(u32) as usual, but toString(class) would iterate through filelds and call toString on them — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVQYW4SHP4GXU2IZ6NPJDWRIH7DANCNFSM6AAAAAATUEAXRQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>