RE: Is there an easier way to deal with "inout" parameters
- From: William Adams <william_a_adams@xxxxxxx>
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Mon, 20 Aug 2012 08:55:06 -0700
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:
