Firstly, this still requires a mechanism which underlies the [ ... ] notation for evaluating a sequence of any number of expressions and constructing a list.
In Lisp dialects, that is done by a variadic function:
(list 1 2 3 4 ...)
Of course, if we don't need to indirect on this function, we could implement it as a macro (supposing further that we have variadic macros for compile time, but not variadic functions for run time).
The macro would turn (list 1 2 3) into the non-variadic calls (cons 1 (cons 2 (cons 3 nil))).
I imagine that's a conceptual facsimile of what Erlang's list constructor notation is doing.
Erlang has variadic features in its read syntax; without a doubt its BNF is chock full of "zero or more of ..." grammar productions. The function defining mechanism lets you define a function which has any number of arguments; just that number has to be fixed for that function. So the mechanism itself enjoys variadic application. Here it is asked to define a three-arg function, here a ten-arg, ...
We can simulate some aspects of variadic application with syntactic sugar, but not all. A Lisp function call which specifies five arguments can call a function which requires exactly five arguments, or a function which requires three arguments, followed by variadic ones.
For instance, if we have a callback registration interface that passes five arguments, the client can supply a fixed arity function, or a variadic one.
I suppose that if everything is static, that can still be worked out. The compiler sees that a variadic function with only two required args is passed as a callback that must be 5-ary, so it inserts a conversion shim: an anonymous function which takes exactly 5 parameters and applies them to the 3+rest function.
LFE macros can have variable number of arguments. The compiler does very little in helping with this as there are in principle no inter-module dependencies. This is a requirement of the dynamic code handling which allows you to reload any module at any time without any requirements on the contents. All checking is done at run-time. This is a basic property of the Erlang system and to make something which is fully compatible you have to follow this.
One way to have made LFE fully variadic in its functions would have been to have made each function only take one argument which is a list of the arguments in the call. This would have been easy to do but made it very difficult to interface LFE with the rest of the Erlang system in a clean way.
In Lisp dialects, that is done by a variadic function:
Of course, if we don't need to indirect on this function, we could implement it as a macro (supposing further that we have variadic macros for compile time, but not variadic functions for run time).The macro would turn (list 1 2 3) into the non-variadic calls (cons 1 (cons 2 (cons 3 nil))).
I imagine that's a conceptual facsimile of what Erlang's list constructor notation is doing.
Erlang has variadic features in its read syntax; without a doubt its BNF is chock full of "zero or more of ..." grammar productions. The function defining mechanism lets you define a function which has any number of arguments; just that number has to be fixed for that function. So the mechanism itself enjoys variadic application. Here it is asked to define a three-arg function, here a ten-arg, ...
We can simulate some aspects of variadic application with syntactic sugar, but not all. A Lisp function call which specifies five arguments can call a function which requires exactly five arguments, or a function which requires three arguments, followed by variadic ones.
For instance, if we have a callback registration interface that passes five arguments, the client can supply a fixed arity function, or a variadic one.
I suppose that if everything is static, that can still be worked out. The compiler sees that a variadic function with only two required args is passed as a callback that must be 5-ary, so it inserts a conversion shim: an anonymous function which takes exactly 5 parameters and applies them to the 3+rest function.