 |
lua-l archive |
|
|
||
|
On 2012-11-17 7:17 AM, "Dirk Laurie" <dirk.laurie@gmail.com> wrote:
>
> 2012/11/17 David Favro <lua@meta-dynamic.com>:
> > On 11/17/2012 03:47 AM, Dirk Laurie wrote:
> >>
> >> Lua has no variables (i.e. preallocated named blocks of memory
> >> the contents of which may change)
> >
> > Except for local variables, including function parameters, for-loop
> > variables, etc.
> >
> You're right. Indeed, those correspond closely to the definition
> in parentheses.
>
> For function parameters, even I might support C-like syntactic sugar:
>
> function myfunc (number a, string b, table c)
>
> if only because most of my functions start off something like
>
> if type(a)~="number" then error(
> "Bad parameter #1to myfunc: number expected, got "..type(a))
>
> The semantics would be that if there are two whitespace-separated
> names, the appropriate argument check is made (the API already
> has the necessary routines), otherwise it's business as usual.
>
Hmm and this could be extended further:
local modes = {"one", "two", "three"}
function f(number 0 <= x < 10,
string mode in modes,
number n matching g,
number 0 < c < 1 matching g > 4)
That would mean x must be a number in the given range, mode must be one of the string values in modes, and n must be such that g(n) returns true.
The last gives a more complex example: c must be in the given range, and g(c) must return a value > 4.
I feel like "matching g(c) > 4" might be more readable, but then you're making a special case where g(c) is not invoking g right where it's written, and doesn't allow for cases like "matching get_a_function()".
It's maybe a bit complex for Lua, but it's an interesting thought.