Re: Is there an easier way to deal with "inout" parameters
- From: Coda Highland <chighland@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 20 Aug 2012 09:26:30 -0700
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:
