Re: Bloat or no bloat? (Was: [Feature request])

["Thiago L." <fakedme@...>]

On 21/09/14 11:27 AM, Dirk Laurie wrote:
> 2014-09-21 15:10 GMT+02:00  <tonyp@acm.org>:
> > Another argument: If everything someone needs is always seen as bloat (by
> > those who don't need it) then Lua development should stop where it is right
> > now.  If Lua is currently in a state where everything (granted, everything
> > for which it was intended) can be handled already, what's the point of
> > further development (other than to fix bugs, or optimize execution
> > performance)?
> Experienced posters avoid the term "Feature request", dishing up
> their ideas as mere topics for discussion :-)
>
> "Bloat" is something that adds to the length of the manual without
> adding to what Lua can already do. For example, if eventually in
> Lua 5.3 "for i in ipairs(tbl)" turns out to be exactly equivalent to
> "for i=1,#tbl" then 'ipairs' will be bloat.
Lua <= 5.2 ipairs is exactly equivalent to:

local t,k,v = t, 0
while rawget(t,k+1) ~= nil do
    k,v = k+1,rawget(t,k+1)
    local t,k,v = t,k,v
    -- your code here
end

(even the starting condition, k=0, is the same)

So it's safe to say ipairs is bloat, right?
> Whether one likes it or not, "conceptual integrity" seems to be a criterion
> in the design of Lua. In practice this means an almost aesthetic judgement
> on the part of the Lua team (BTW has it ever happened that Roberto got
> outvoted? That would be an interesting anecdote!)
>
> For example, it's quite easy for a table to know exactly how many keys
> it contains. One extra integer in the struct plus a test whether 'nil' is being
> assigned when it's not a new index or non-nil when it is. That feature has
> been requested on this list. It has not been implemented in core Lua.
> There's a tradeoff on how useful it is versus what it costs, and the
> decision went against it. Fair enough.
>
> One can get an idea of what is considered to be non-bloat by looking
> at the most recent alpha.  Lua 5.3 has one addition to the core (64-bit
> integers and operations on them) and one main addition to the standard
> libraries (UTF-8 codepoint parsing). Both offer great extra functionality.
> Both were envisaged long before when Roberto gave a talk on "What
> is next for Lua" at the 2012 workshop.
>
> What we should be rooting for is not little tricks borrowed from Python,
> Ruby, Perl or Javascript. We should be trying to persuade Roberto that
> some of the other stuff he mentioned will also be appreciated by the
> community. That's "lpeg" and/or "struct". Do we really want to do
> decoding of strings representing byte blocks using numerous feeble
> little functions with clumsy names like string.undumpint etc? Or do
> we want something that can offer power comparable to C's sscanf?