[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Some crazy stuff (was Lua 5.3 changes to .__eq)
- From: Mike Nelson <mikestar1313@...>
- Date: Tue, 14 Jul 2015 00:10:06 -0700
On 7/13/2015 11:06 PM, Sean Conner wrote:
With regard to the proposals from the list, mostly too complicated, has
too much run time cost (especially proposals that would impose run time
cost on code that doesn't use them) , breaks existing code, or is just
not to my taste. I am OK with proposals that are uncomplicated to code,
have trivial to zero run time cost, and break no existing code (except
perhaps some very rare, very weird edge cases): if it isn't to my taste,
I won't use it.
It was thus said that the Great Mike Nelson once stated:
In my heavily hacked personal copy of Lua which I use for
experimentation, I go one further: If either operand regardless of type
has an .__eq metamethod, a==b returns the result of the appropriate
metamethod even if rawequal(a,b) returns true, thus allowing such
atrocities as 7==Complex:new(7,0) to return true and a==a (where a is a
usertype with a nan-like value) to return false. I'm now working on the
C code to have a>b call a's .__lt metamethod if both operands define
metamethods, and to have a<=b in the absense of .__le metamethods but
the presence of .__lt metamethods be evaluated as (a==b) or (a<b) rather
than the current not (b<a).
The above is strictly for fun and contains no serious proposals, but I
have used my hacked copy to experiment with changes suggested on the list.
How have some of those changes worked out?
Enabling x:[expression](...) method call syntax is fairly easy to code
and cheap to execute (as it affects code generation, not execution).
This is an example of a good proposal, IMHO: it doesn't have any run
time cost, doesn't break any existing code (that doesn't depend on
x:["get_"..propname](), for example, being an error) and doesn't require
anyone to use it as x[expression](x,...) still works; by the way, I like
this one. I wouldn't mind the %m format specifier proposed in a recent
post. Again it breaks nothing, imposes trivial run time costs, as does
something that some users will like (it isn't necessary: as Roberto said
%p can be used, but to auto escape strings which may contain magic
characters while lengthening the output string as little as possible, it
is quite useful: %p will cause some punctuation marks that don't need to
be escaped to be escaped). I am indifferent to this one.
With regards to my own stuff mentioned above, they all fail as changes
to Lua by the above criteria--some are useful for the purposes of
creating my own language which runs on a modified Lua VM, which I don't
expect to match Lua's performance, but I do expect it to beat the same
idea implemented on top of Ruby, for example. This is a project I have
undertaken in order to learn how to do it, incidentally brushing up my C
-- Mike Nelson