Is it possible to splat into ccall?

[lmtzx9h4qqnt]

@Sukera

The error you see is a syntax error, because ccall needs special casing during parsing/lowering to be able to be passed through the compiler and handled as a foreign call, as well as for inserting the calls to cconvert and unsafe_convert.

This doesn’t seem to match with @c42f’s statement in the linked thread:

@c42f

The basic answer

It doesn’t need to be syntax. @ccall is a more recent and much more attractive syntax for the same thing which doesn’t need special support from the parser or lowering.

Not sure who’s right here?

@Sukera

Since it fails at the syntax level, there is no later type based compiler magic you can do to fix this, you need to (at minimum) change how ccall is handled in parsing & lowering.

Yes, this is what I’m saying: This shouldn’t fail at the syntax level. The length check should instead be done at compile- or runtime.

@Sukera

@ccall is the “escape hatch” that we use right now in lieu of modifying the parser to make ccall more special - not to mention that any change to the parser there needs to be backwards compatible with the existing syntax, as to not introduce a breaking change.

What I’m arguing for is making ccall less special. Normal function calls in Julia don’t behave like this syntactically, and given that it looks the same, it would be better for ccall to behave as closely to a normal function call as possible.

@Sukera

The relevant Scheme code in the parser is here and here. There is a mention of ... in there, so it does already seem to be aware of varargs to some extent, but not so far as to allow splatting of arguments

The ... in the code refers to specifying varargs in the type signature, as in

julia> ccall(:printf, Cint, (Cstring, Cint...), "%d %d %d\n", 1, 2, 3);
1 2 3

which is yet another special-case syntax that only exists within the context of ccall.

@Sukera

but not so far as to allow splatting of arguments (likely in part because we’d still need to know how many arguments we actually want to pass during link time, if I’m not mistaken)

I don’t know if “link time” refers to something else in the context of Julia, but in C, you can link to functions perfectly fine without even specifying any function signature. And of course, with varargs you’ll also never know how many arguments are going to be passed, and this number can change, too. So I’m not sure what the problem would be here.

@Sukera

This is something the @generated approach avoids via sleight of hand, by not splatting at runtime, but during compilation/parsing, when the @generated function is compiled for the passed in (known & fixed length) arguments.

And the result is a clearer, more consistent, and more flexible syntax, even within the constraints of the current implementation of ccall. Wouldn’t it be better if ccall worked like this?