• Subject: Re: Syntax sugar for default arguments
• From: Andrew Starks <andrew.starks@...>
• Date: Thu, 25 Apr 2013 10:05:13 -0500

Where all of this goes wrong is when I think of tables and up values. If you said that default arguments must always be literals, that *might* solve something. it gets hairy when you contemplate:

a = function(arg1 = 3, arg2 = {"first value", x = d, } or old_value or error("arg2 is required"))

What happens if arg2 is set, but the first value and/or x is not set? Are we saying, if no table, put in these defaults and if there is a table, don't put any defaults in, or fill in the missing defaults? Where is the boundary of defaults? Is it enough to just say that defaults are not recursive and that if anything is provided, than the entire default argument is discarded?

There are two topics that keep getting brought up and I think that it's repeated because there is a genuine need to clean up some common and tedious idioms. First is the frequent:

local table, string, etc = table, string, etc

second this one, which is to eliminate:

a = function(arg1, arg2)
arg1= arg1 or 3,
arg2 = arg2 or {"first value", x=d} or old_value or error("arg2 is required")

I think that the most compelling case is that there is no equivalent assignment syntax to the "lone table argument" calling syntax. If default arguments were allowed only for the "lone table argument" variety, this would be very welcomed and to my thinking, would be a "Lua amount of sugar." Something like:

a=function{arg1 = arg 2 = {(as before)} or (as before)}
assert(type(arg) == "table", "The only way to see this is if the user passes in a non-table as the first argument")

--or alternately

assert(type(({...})[1] == "table", (as before))

The only reason that I think the former might be better is because it distinguishes between the normal meaning of "..." (unknown number and type of arguments) and the fact that we really do expect a table as the first argument, in this case.

Okay, I know that others are tired of this topic. I'd only remind the annoyed that perhaps it is a sign that there is an improvement in simplicity to be found somewhere in these areas of interest.

-Andrew

On Thu, Apr 25, 2013 at 12:48 AM, Tim Hill wrote:
Well my personal opinion is it's bad design to do that anyway. I always train people to think of a Lua function as one that has as input an infinite number of arguments, most of which are nil, and returns an infinite number of values, again most of which are nil.

--Tim

On Apr 21, 2013, at 6:47 PM, Coda Highland <chighland@gmail.com> wrote:

> On Sun, Apr 21, 2013 at 6:31 PM, Tim Hill <drtimhill@gmail.com> wrote:
>> Why can't you just use a wrapper function? Trivial to do, and doesn't need any patching:
>>
>> function g(x, y)
>>        f(x, y or 0)
>> end
>>
>> And of course, it's easy to wrap transparently:
>>
>> do
>>        local fo = f
>>        function f(x, y)
>>                fo(x, y or 0)
>>        end
>> end
>>
>> --Tim
>>
>> On Apr 20, 2013, at 11:41 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>
>>>   function f(x,y=0)
>>>   function f(x,y or 0)
>>>
>>> to mean
>>>
>>>   function f(x,y) y=y or 0
>>>
>>> Neither would break existing code.
>>>
>>> Which of the above should I choose to implement as a patch?
>>>
>>
>>
>
> I'd rather do it in the language instead of in script, because you may
> still care about the difference between nil and not having passed a
> parameter at all.
>