Re: A coding challenge: was: luaD_precall() question

[Coda Highland <chighland@...>]

On Sun, Jul 2, 2017 at 6:07 AM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Hi,
>
> On 2 July 2017 at 01:50, Coda Highland <chighland@gmail.com> wrote:
>> Well, let's see here.
>>
>> If you support four integer types, two floating-point types, void, and
>> nothing else, then you can handle no parameters or one parameter and
>> one return type easily enough, but you can't fit two parameters (that
>> would need 343 distinct values and you only have 255).
>>
>> If you require all of the parameters to be of the same type (this
>> would let you use most math functions) and explicitly encode the
>> function's arity, then you only need six input data types instead of
>> seven; you could support up to five parameters this way using a total
>> of 217 values. This leaves 38 more slots available, which you can use
>> to encode some common other signatures, such as (void*), (void*,
>> size_t), and so on. (Since this is C and not C++ you don't have to
>> worry about encoding the specific type of the pointer.)
>>
>> You could also support up to three parameters of the same type, or a
>> void* and up to two parameters of the same type, and that would use
>> 224 values, leaving 31 slots for special-case parameter lists.
>>
>> If you put some restrictions on available return types (e.g. restrict
>> the choices to "void", "same as the parameter list", and "pointer")
>> then you can squeeze out even more options but I don't feel like doing
>> the math for how many that is, and you might need to use some special
>> cases for 0-ary functions that return a value anyway.
>>
>
> Indeed - using a single byte allows me to encode 255 signatures. The
> challenge is more how to map the signature and the actual types to a
> function pointer without gong through a lot of branchy type checks. So
> I want a hashing function that is as follows:
>
> map(function_signature_code, actual_parameter_types[]) -> function pointer.
>
> The idea is that good values map to appropriate function pointer that
> can be invoked. Bad values (i.e. wrong parameters on Lua stack) - map
> to a special error function.
>
> I want to do this mapping almost as a lookup table ... but the problem
> with a lookup table is that it would have to handle all possible
> values and have to be multi-dimensional. But conceptually this is what
> I would like to do.
>
> Thanks and Regards
> Dibyendu
>

My point (which I failed to make clear, my fault, I got carried away
in speculation without giving the actual concrete idea I had) is that
you can encode the stuff numerically without using too many branches.

if arity == 0 then
  signature = 1 + returnType + 42
elseif arity < 4 and not hasVoidPointer then
  signature = 1 + returnType + (parameterType * 7) + ((arity - 1) * 42)
elseif arity < 3 then
  signature = 1 + returnType + (parameterType * 7) + ((arity + 3) * 42)
else
  -- now you can use a small sparse lookup table for the rest of the exceptions
end