Re: Adding several methamethods could be helpful

[Francesco Abbate <francesco.bbt@...>]

2011/3/27 Fabien <fleutot+lua@gmail.com>:
>> Ideally, a library knows best how to handle a complex expression of their
>> own objects. [...]
>> Could Lua call my mydream library with the AST of "A=(B * C + D) * E"
>> instead of evaluating it itself somehow?
>
> At compile-time, with a dynamically type language, you don't know the types
> of A, B, C, D, E, so you have no idea which library could handle them. At
> runtime, either the AST is lost, or you have to perform some sort of
> re-compilation step, which would be grossly expensive in time and resources.
> What you're proposing would be doable in a statically-typed language--C++
> templates are not that far away from that, actually--but you can't have that
> in something that even remotely feels like Lua.

I'm thinking to this problem since a lot time now because for the
matrix it would be very useful to not evaluate every single step to a
new matrix. I don't have a solution for the problem but I was thinking
that a sort of lazy evaluation could work. Here is the idea. When you
type an expression like A+B the object that is created is a new type
of object that just store the information that a sum of A and B should
be done. Then, when this object is inspected, for example to obtain an
element at some position of the matrix, you could evaluate the object
on the fly and replace it with the real matrix. This could be done
easily with Lua metatables, for example, if m is C a not-evaluated
matrix then

-- retrieve a matrix element
C:get(1,2)

could cause the evaluation of the object. This could be done also if
the C API side using the same logic. The problem that I see here is
that if a local variable point to a not-evaluated object it will still
point to the same object even if its evaluation happens at same point.
I guess that the object replacement can work only when the object is
passed as a function argument because you will just replace an object
with another in the Lua stack.

-- 
Francesco