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

[Thomas Jericke <tjericke@...>]

On 04/09/2014 11:44 AM, steve donovan wrote:

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