Re: Is there an easier way to deal with "inout" parameters

  • From: Jay Carlson <nop@xxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sun, 19 Aug 2012 23:04:11 -0400

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 

  "$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", 

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.


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.                                       

Other related posts: