[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: More on environments and objects
- From: Mike Pall <mikelu-0508@...>
- Date: Sun, 28 Aug 2005 15:17:42 +0200
Hi,
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
directions.
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: http://www2.imm.dtu.dk/~riis/PPA/ppa.html
Bye,
Mike