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

  • From: Jay Carlson <nop@xxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Mon, 20 Aug 2012 12:57:11 -0400

So the proposal on the table is:

  local len_ = {[0]=0}
  getvalue(nil, len_)
  print("length is", len_[0])
  buff = ffi.new("uint8_t[?]", len_[0]);
  getvalue(buff, len_);
  return ffi.string(buff, len_[0]);

The optimizer shouldn't have a fundamental problem with that, since it can know 
getvalue() doesn't mess with anything important about len_. 

Teh Lua Way would be len_={0} but I just don't see that being very helpful. To 
use tables as boxes you need a distinguished key, and {[0]=v} is very natural 
for talking to a language where a[0] === *a.

Jay  

On Aug 20, 2012, at 12:26 PM, Coda Highland wrote:

> Sure, it's different for the FFI than for pure Lua. But it sounds like
> you have a workable (if awkward) solution for FFI use, so if you're
> looking for a way to expose similar functionality to Lua, there's no
> need to extend the language, because parameters with reference
> semantics already exist.
> 
> /s/ Adam
> 
> On Mon, Aug 20, 2012 at 8:55 AM, William Adams <william_a_adams@xxxxxxx> 
> wrote:
>> In my original case, this is about interop to a C function through FFI.
>> ________________________________
>> From: Coda Highland
>> Sent: 8/19/2012 8:39 PM
>> To: luajit@xxxxxxxxxxxxx
>> Subject: Re: Is there an easier way to deal with "inout" parameters
>> 
>> 
>> I'm going to make a rather simple comment:
>> 
>> Use a table.
>> 
>> Remember that tables are passed by reference. So if you want an inout
>> parameter, consider taking a table as a parameter, and after the call
>> the table's members will have been mutated appropriately.
>> 
>> /s/ Adam
>> 
>> On Sun, Aug 19, 2012 at 8:04 PM, Jay Carlson <nop@xxxxxxx> wrote:
>>> 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.
>>> 
>>> 
>> 
> 


Other related posts: