Re: boolean operators

[Glenn Maynard <glenn@...>]

On Thu, Sep 21, 2006 at 09:49:58AM +0100, Lisa Parratt wrote:
> Roberto Ierusalimschy wrote:
> >May I ask you (and others) why you need boolean operators in Lua? (This
> >is not a rhetorical question. I really want to know what uses boolean
> >operators may have in Lua.)
> 
> Why shouldn't we want boolean operators in Lua? Who're you to define 
> whether we need them? Unless you're up their with Babbage or Turing, you 
> certainly aren't in any position to dictate, which is why they're one of 
> the features commonly hacked into Lua. Functions just don't cut it when 
> you need performance.
> 
> I'm getting exceedingly sick and tired of the way us users are treated 
> like children. Just the fact it's so commonly requested ought to be 
> enough reason for them to be added.

It seems like you're saying "lots of people have asked for it, so you
should just add it, not expect us to explain why".  I've dealt with my
share of that in other projects: the notion that I (as a free software
developer) am obligated to add something, and not even because of good
reasons being given--merely because a bunch of people asked for it (and
eventually turn demanding, and get annoyed that I keep asking people
"why?" when I'd never seen an explanation that convinced me).  He has
every right to dictate what goes into the language, and the excellent
balance of practical, real-world usability versus bloat tells me he's
doing a damned good job.

"Performance" can be cited as a reason for adding special syntax for just
about any feature.  It's taking one case where a few people want to do
something faster, and adding syntax to the language to streamline just
that case.  I think someone recently asked for an "append to table"
operator for the same reason.

It seems like it would be more useful to find a way to allow Lua
implementations to optimize particular function calls, like C compilers
treat common function calls (eg. strcpy) as intrinsics to allow extra
optimization.  In principle, it should be possible to peephole eg.
"math.and" down to the same code that you'd get with an operator,
without adding new, specialized syntax.  The same thing could then be
applied to table.insert.

Some obvious issues: "math.and" might not be "math.and"; "math" might
be some other math package, the math library might not be loaded,
or it might be hooked through another table to track its use while
debugging.  Still, it seems a more scalable line of thought than adding
operators to the core language to achieve the same effect ...

-- 
Glenn Maynard