Scarpet functions should be able to receive a variable number of arguments. This would, for example, be useful for commands, as having a variable number of command arguments is currently impossible.

I suggest the following syntax:

a(arg1,arg2,args...) -> (
  print('arg1 is ' + arg1);
  print('arg2 is ' + arg2);
  print('other args are: ' + args)
);
a(1,2,3,4,5) // should print 'arg1 is 1', 'arg2 is 2', 'other args are [3, 4, 5]'

In other words, if the last argument has ... following it, it should be a list containing the remainder of the arguments the function received.

just have one arg which is a list, so the length is variable, no?

Related to #221 in the command part, although not for the function part, which I don't see the necessity since you usually know the arguments you are passing from the program itself.

just have one arg which is a list, so the length is variable, no?

This does not work when running functions as commands, unless you want the user to enter a list, which is both cumbersome and more complicated than necessary.

Related to #221 in the command part, although not for the function part, which I don't see the necessity since you usually know the arguments you are passing from the program itself.

This approach does not require any changes to previously written scripts (unlike the suggestions in #221, all of which included some sort of extra metadata), so it would be backward-compatible with the previous command system, and furthermore it seems unfair that the language's standard library has functions which support variable numbers of arguments (take l() for example), but functions written in the language itself cannot. I think this is a simple solution, both to the average Scarpet programmer (no messing around with metadata), and to the average user (no need to update old stuff). It allows for maximal flexibility while also remaining backward-compatible, without having to reference the documentation all the time for the metadata format. In other words, it seems like the ideal solution.

That's actually a nice suggestion, but I fear that it may be hard to actually implement, as in the code itself it is hard. But I can look into it over the weekend as it may be helpful in my current work on the command system

command arguments for now do not support lists, only primitive types (for security reasons). Brigadier (command system) doesn't support lists either.

Having said that leaving the tail arguments would be relatively easy to add. I think its a cool suggestion. Might need to check how much perfomance hit that would make, if any. Since the parser only allows for prefix unary operators, the syntax would need to be fun(foo, bar, ... baz) -> (body);

command arguments for now do not support lists, only primitive types (for security reasons). Brigadier (command system) doesn't support lists either.

Then it is not possible at all to have an unpredefined number of arguments in a command? Even the more reason to add it.

Having said that leaving the tail arguments would be relatively easy to add. I think its a cool suggestion. Might need to check how much perfomance hit that would make, if any. Since the parser only allows for prefix unary operators, the syntax would need to be fun(foo, bar, ... baz) -> (body);

Should this be considered an operator though? It probably depends on how many things are operators internally. This seems like a nice compromise though. Thank you for the consideration.

well, I am not even attempting to mess up with brigadier. And commands would need to go through brigadier anyways, so that's about that.

There are only functions, operators and literals in carpet, nothing else. Any syntactic sugar notations need to fit in one of these categories.

e8b2060