Re: ipairs in Lua 5.3.0-alpha

[Coroutines <coroutines@...>]

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))