Re: 'in' keyword today (was Re: mathlib)

[On Wed, Apr 9, 2014 at 11:39 AM, Thomas Jericke <tjericke@indel.ch> wrote:

And "in" is the keyword it should be, if this would be "from", then it would
be "from" in the for loop as well.

Of course, that was Luiz' comment as well.
But beware of overcomplicating a simple mechanism.....

It's not my intention to overcomplicate a simple mechanism, what I want is a mechanism that broad enough to cover several use cases and not just a single one.

My current idea is about as complicated as the "in" statement within the generic for. Which is not that simple, I have to admit.

From the manual:

 for var_1, ···, var_n in explist do block end

is equivalent to the code:

 do
 local f, s, var = explist
 while true do
 local var_1, ···, var_n = f(s, var)
 if var_1 == nil then break end
 var = var_1
 block
 end
 end

Now the non-for "in"

 var_1, ···, var_n = varname_1, varname_2 ... varname_n in explist

is equivalent to the code:

 
 local f, s = explist
 local var_1, ···, var_n = f(s, "varname_1"), f(s, "varname_2") ... f(s, "varname_n")

Were "varname_1" means that this literal is passed as a string to the function. The idea here is that f is an "indexer" function instead of a iterator function.

I think this general approach would solve several cases.

local a,b,c in assert_index, require "mylib"
local x, y, z in _ENV
local sockets, mysql, json in require -- loads several libraries as local tables

> personally I'd find it cool if the "in X" could also point to a string literal which is required.

I don't really like to get "require" getting involved here. IMO the "in" statement should simplify the assignment of many locals from a function or table.
It should be up to the user to chose from which function or table.

-- 
Thomas