As lua-l readers are all too aware, I'm interested in language meta-extensions with Lua spirit. One of my particular hatreds is writing the same thing twice in a row, or having to match up parallel parameter orders. The usual examples are "$pronoun had $jobcount jobs." % {pronoun=pronoun, jobcount=jobcount} query("SELECT * FROM trips WHERE person=? AND destination=? LEFT INNER JOIN ENOUGH sql_nonsense TO KEEP parameters OUT OF shouting_distance", "Steven", "Mora") I have a couple of mechanisms to deal with those. But they're all about getting the values of lexical variables *in* to a little language, not how to get them out. My proposal below of "buff,len=getvalue(nil,len)" has just the repeat-yourself issue particularly irritating to me. So I understand the desire behind inout, and I'm now irritated with myself for not poking around in that side of the design space. Jay On Aug 19, 2012, at 9:04 PM, William Adams wrote: > Yah, I realize that this is not a practical wish. I could probably be > managed for FFI cases, but then the language would start to gain some weird > semantic garbage. I guess I'll just have to man up and keep toughing it out. > Probably a better scanner/converter could spot these, and come up with > proper wrappers where necessary. but, realistically, it happens infrequently > enough that all the cases will need to be hand inspected and tuned anyway. > > =============================== >> >> This is something a PUC-Rio Lua implementation of ffi would not be able to >> do. >> >> Adding inout for ffi alone seems odd. For consistency, straight Lua >> functions should have this ability too. Saaaay, what happens when you put >> something which isn't a local lvalue in an inout slot? >> >> Multiple return values, as in >> >> buff, len = getvalue(nil, len) >> >> would not be as nifty, but preserves immutability of parameters, and has >> well-defined semantics.