lua-users home
lua-l archive

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


On 7/13/2015 11:06 PM, Sean Conner wrote:
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?

   -spc


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.

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 skills.

-- Mike Nelson