lua-users home
lua-l archive

Re: ipairs in Lua 5.3.0-alpha

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

On Tue, Aug 5, 2014 at 7:02 AM, Daniel Silverstone
<dsilvers@digital-scurf.org> wrote:
> Such a level of flexibility would severely limit the analysis of code. There's
> a reason C++ doesn't allow overloading of operators on intrinsic types; and
> similarly there's a reason Python's so very hard to write a fast interpreter
> for.
>
> "interesting" it may be, but "sensible" "efficient" and "worthwhile" I'd argue
> it would not be.
I do not disagree -- I can't think of practical advantages to having
base mechanics exposed this way. (Also I know I'm very off-topic)
I think I remember a while back wanting to make sure division could
never return NaN -- I wanted to make 0 / 0 return "nothing". It had
me thinking about this because I wanted to wrap the __div C code
without touching any C. I just thought if Lua did this it would be a
very flexible language -- but it'd also need some way to replace the
"constructor" for literals. Like, it'd be nice to have 0 appear in
the source and call a third-party bignum constructor. I definitely
agree this level of flexibility would only make Lua slower.
Personally I would not mind it as I know Lua to already be so fast --
not suitable for everyone but maybe my own pet projects :-)
PS: I also wanted the ability to set an initial metatable on the table
type, which could be the `table' library :p Yes we all have
constructors but it's so nice when you can monkey patch third-party
libraries that just "a = {}"
PPS: I'm so very very off topic... T.T ((sorry))

AltStyle によって変換されたページ (->オリジナル) /