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

[Coroutines <coroutines@...>]

On Tue, Apr 8, 2014 at 9:18 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
> *   I prefer my localized standard functions to have a prefix (like
> `t_concat`), because locals like `len`, `insert`, `remove` (already
> ambiguous), date, time, find, match, sub, byte, etc. are likely to appear in
> my own code. The namespace is an important part of the function's name,
> IMHO.

I think I would suggest both an 'in' and 'from' so this would be possible:

local a, b, c in some_table
local t_concat, t_insert = concat, insert from table

Basically 'in' would retrieve the values of the associated keys in a
table, and declare them (local or global).  'from' would be the more
general one returning a vararg of the values matching the identifiers
'from' the table.

On a side-note I've been thinking about extending my table.import() to
allow filtering by value or key type in the table imported from.

Currently for your table example it can do this:

table.import(_ENV, table, 't_', { 'concat', 'insert' })

The concat/insert part is a sequence because for the 3rd parameter you
can either specify the prefix or the sequence of which specific keys
to pull.  a vararg would not work where the sequence is.

I'm thinking about making it of the form:  table.import(into, from,
options{}, ...)

So one could do this: table.import(_ENV, table, { keytype = 'string',
valtype = 'function', postfix = 't' }, concat, insert)

This would make it only import keys that are strings from the 'from'
table, and the references it makes in the 'into' table would have a
't' suffix.  _ENV.insertt, etc...  (I want to allow for both a prefix
and/or suffix if need be)

I guess a more general form would be making keytype and valtype into
functions that can be mapped over the keys and values --
keyfilter/valfilter being predicates.  I dunno, I put more than one
idea in this post, sorry I'm a little disorganized..