[StreamBright]

This is a feature to me more like a limitation. I do not like optional arguments &rest style. In Erlang you need to have explicit number of arguments and need to explicitly implement them. I really like that. Keep in mind that default values are trivial to implement when the smaller arity function calls the higher arity one with added values. Or you can call in yourself to the higher arity function and specify the parameters yourself. In my opinion this is elegant and safe way of dealing with the problem.

[seiji]

In Erlang you need to have explicit number of arguments and need to explicitly implement them.

Or, you know, just use lists as parameters. That's the standard Erlang pattern for unknown parameters lengths (e.g. io:format("debug ~s because ~p~n", [SomeString, SomeType]))

[kazinator]

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.

[rvirding]

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.

[StreamBright]

I think io:format has fixed number of arguments(2), the text that you use as a template and the second parameter is a list of things that you will be using in the template.

[technomancy]

I feel like it's OK not having rest args if you leave them out in order to support currying, but leaving both out seems really weird for a language that's trying to be functional.

[yurrriq]

We can have rest args in LFE via something like

    (defmacro foo args
      (do 'something (with args)))

where

    (and (>= (length args) 0)
         (=< (length args) 255))

Note the lack of parentheses around args in the defmacro form.

Edit: Oops, Robert mentioned this, too.

[kazinator]

Leaving out rest args supports the syntactic sugar for currying, not currying itself. (Let's call that sugar OAIPA: omission of arguments is partial application.)

Even syntaxes which have OAIPA can (and do) still have optional parentheses to exactly delimit the arguments of a call, and that notation can clearly support variadic args.

Outside of explicit delimiting with parens, OAIPA can work on a variadic function up to its required arguments by considering it to be a function of exactly that number of arguments, and no more.