lua-users home
lua-l archive

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


On 27-Sep-06, at 6:00 PM, Glenn Maynard wrote:


On Wed, Sep 27, 2006 at 04:24:23PM -0500, Rici Lake wrote:
This applies to every operation. pow() is no more cleanly overridable, 
or any of the myriad of operations a bignum class would want to
implement.
This isn't an argument for div and mod in particular.


yes it is. just set the __pow metamethod.


(I didn't even know Lua had a ^ operator.  Eh.)
The fact that you happily program in Lua without being aware of the ^ operator demonstrates, I think, that extra operators do not necessarily get in your way, don't you think? 


But you missed the second half of my sentence: what about math.min,
max, abs?  All things that a bignum implementation would want to
overload.  Why don't they get operators, too?  Complex or rational
number types would want to overload most of math.
Yes, it's hard to know precisely where to draw the line. I don't think max and min are math operations, myself (they certainly apply to strings), and if max and min were added as operators (or inf and sup), I probably wouldn't object, but see below. 


(Aside: it works fine, actually, the metatable just isn't set by
lmathlib.c like it is by lstrlib.c.)


Yes, and it probably should be.


function quad(a, b, c)
  return b:neg():plus((b:squared()
                       :minus((4):times(a):times(c)))
                       :sqrt())
          :div(2):div(a)
end


(According to this little reduction-to-absurd, every function
should be an operator, and suggesting that any function should
not be an operator leads to absurdity.  That's, well, sort of
absurd ...)


Of course, it's absurd. (But it's kinda cute.) The only point was
that there is no absolute answer to the question of what should
be an operator and what shouldn't be. It's a balance which
includes convenience, esthetics, and (yes) efficiency, and we
would probably each draw the line at a different point.

In fact, we might have different preferences over the course
of time, depending on what we happened to be working on.
For example, in one project I had, I wanted all of the
trig functions to have been unary operators; since they're
not, I hacked the parser to allow the syntax to work. But
I don't know that I'd want that much namespace pollution all the
time.


It adds up in the net complexity of the language: another operator
for everyone to understand, another metamethod to overload it, another
operator to define precedence for.  I think it adds up very quickly.
Well, the nice thing about % (and //) is that they don't add any precedence levels. I agree that adding precedence levels 
complicates things very quickly -- I can never remember all of
C's, for example, and always over-parenthesize bitwise operators.
So perhaps one of the criteria would have to do with that.

As far as "another metamethod to overload", that's no different
from "another library method to overload", as far as I can see.

And, as I mentioned earlier, you don't have to learn about an
operator if you don't need it.

Contrary to the (incorrect) subject of this message, I'm not
one of the people pushing for bitstring operators. If bitstrings
were a fundamental type in Lua, then most of the common bitwise
operations could be assigned to other existing operators; other
ones could be library functions or whatever. But bitstrings are
not a fundamental type in Lua, and, however useful they may be
for my personal applications, I'm perfectly content to implement
them with an extension library (which does overload existing
operators). Faking bitstrings by pretending they're integers
does not solve any problems I have (i.e. I would still need
my bitstring objects because I need bitstrings of unlimited
length.) In fact, the "bitwise operators on numbers" proposal
strikes me as inelegant. But that's just me.