Op Ma., 17 Sep. 2018 om 09:23 het Eike Decker <zet23t@googlemail.com> geskryf:
> There are other cases where it would be useful to be able to return objects. For instance a vector math library could define that the comparison operator compare each scalar value individually and returns a new vector containing only 0/1 values.
>
> But currently, this is not possible (it seems?).
> Is there any particular reason why it is important to convert returned values that I don't see?
Yes, there is. One can deduce the existence of the reason from the
explcit sentence "The result of the call is always converted to a
boolean. " in the manual.
That does not mean that anybody outside the Lua team knows the reason,
but here is a guess.
There is no '__ne', '__ge' or '__gt': they are defined implicitly via
"__not" and are therefore always boolean. It would be very illogical
to break the identity 'a<b == b>a'.
I don't see a problem with not having a __gt / __ge metamethod, it currently simply swaps the operators when calling the __lt / __le methods - which is fine for symmetric operations. The missing __not metamethod is probably a good reason why it works how it does right now. It feels unsatisfying though. Having a few more metamethods instead and going through a greater length of implementation would be not the problem in the average case I guess.
I’d have a use case for these as well. I’m using operator overloading to great success in generating HLSL / GLSL / whatever back-end shader lang variation from shader code written in Lua:
I can do arithmetic ops & bit ops, but not relational ops. For rel ops I have to use functional style e.g. less(a, b) which when mixed with regular infix notation produces hard to read & maintain code.
One day I hopefully have some time to hack a custom version of Lua for the shader compiler...
Petri |
