|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
| timo | there's also the opportunity to have a "proto sub" for a variadic C (or other native) function that has the information about "variadicness" on it, and then one or many multi candidates for specific annotations going from specific to general | 00:09 | |
| could even be the same trait for proto sub vs only sub | |||
| japhb | Oh now that's an interesting usage (variadicity as a proto trait). | 00:27 | |
| timo | i think it makes sense from a "hook to hang it on" but it'd be annoying to have to make a proto + at least one multi for any vararg native function | 00:28 | |
| proto and multi do have the syntax to put a "don't use anything to the right for deciding the right multi candidate" which is kind of the opposite of what we want here | 00:29 | ||
| i think it's ;; in the parameter list | |||
| and of course we might want to have a multi where each sub is bound to a different native symbol, so forcing the trait to be on the proto wouldn't be nice for that | 00:30 | ||
| japhb | Hmmm, decent point. | 00:35 | |
| I feel like it would be useful to get as close to `sub foo(*@args) is native {}` as we can would be nice, because slurpy arrays are the closest equivalent I can think of for variadics. | 00:39 | ||
| One possible way to think of it might be a sub-Signature applied to a Capture. | 00:40 | ||
| `sub foo(|c (Str, Str, Int)) is native { }` | 00:41 | ||
|
02:34
JimmyZhuo joined
02:35
JimmyZhuo left
|
|||
| nine | Variadic calls don't differ from normal calls very much. In the end, it only comes down to the number of 64 bit integer and 128 bit float arguments respectively. There are no other argument types (on x86-64 but from a quick glance, ARM is similar). | 07:46 | |
| We may need some extra information for Raku though like the mentioned is rw or string encodings. | 07:48 | ||
| In any case, these are certainly properties of the call site. After all the point of variadic functions is that the argument list can be different for each call. | |||
|
09:36
sena_kun joined
10:14
sena_kun left
|
|||
| patrickb | Can we move this discussion to github.com/Raku/problem-solving/issues/473 | 12:21 | |
| I hope that makes keeping track of the different ideas easier. | 12:22 | ||
| nine: Yes, it's not much different. In dyncall it's two additional calls to dcMode() to set the mode before the first fixed arg and before the first dynamic arg. | 12:23 | ||
|
12:24
JimmyZhuo joined
|
|||
| patrickb | But the question I think needs to be solved is where the types of the dynamic args come from. I agree it's a thing of the call site as long as we don't want to reduce the system in so far as having to specify each different type variant in a new declaration. (That's approach 1. in that p-s issue). | 12:26 | |
|
14:24
JimmyZhuo left
|
|||
| timo | ah, amd64 system V abi has the number of floating point arguments inside the rax register | 15:59 | |
|
18:47
sena_kun joined
23:11
sena_kun left
|
|||