lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Rici Lake wrote:
> By the way, I checked the 5.1work6 code. It still insists that objects 
> have the same (lua) type in order to be compared, so it won't do what 
> you want. It would be easy-ish to change the check to "same metamethod" 
> with a little jiggling.
> [...]
> I haven't tried any of that, and I'm don't think I like it. I would 
> certainly want to have an non-overridable object equality primitive in 
> the language ('is' '===' or however you spell it).

I don't like any of that, too. Please, never corrupt Lua
with stuff like that.

Apart from language design aesthetics, there is another good
reason I stumbled across recently: requiring type identity
in comparisons helps with program analysis (as used in an
optimizing compiler).

I.e. when you encounter something like 'if a > 0 then ...'
you can do type inference for both forward and backward

You can infer that 'a' must be a number _after_ that comparison
(in both branches). Because otherwise you'd get an exception
that breaks the control flow.

Conversely you can infer a strong hint that 'a' should resolve
to a number _before_ that comparison.

Often enough a comparison is the key hint you need for the
analysis of a freestanding function. In the context of a JIT
compiler you get most type hints from passed parameters of
course (but these are only hints and must be checked at runtime).

While I'm at it, I should note that the addition of generic
metatables weakens the precision of the analysis in some cases.
E.g. one can no longer infer that obj in 'obj:method()' must be
a table or userdata (which allowed some shortcuts).

Canonical reference: