At leastr someone looking at it.
Lua will probably come later with a new API in its default library like table.tune(t, {parameters}) to pass an array of tuning parameters
May may be later a syntax that can be used in table constructors like {?tune={parameters}, 1, 2, 3 }
or simply using tunning parameters in the environment like just: table.defaults{parameters}; ...: {1,2,3}.
The parameters could be implementation-dependant (parameters for the sequenced store, parameters for the hashed store, with parameters like: [roundup]=16, [factor]=200, [low]=25, [high]= 85.
Implementations would use the tuniong they want, and table.default() called with no parameter or an empty table would not change anything, but would return the current local parameters kept in a separate table so that application could save these parameters in some variable, and set some other parameters (one or more, not necessarily all), before passing the saved parameters again to table.defaults():
local state = table.def()
do
-- Set other defaults, so that initial minsize is 16 (growth reduction of size will be rounded up to multiple of 16 slots
-- with a growth factor of +50% instead of +100%, and reduction factor by 1/1.5, i.e. -25%
-- no minimum fill level=0%, maximum fill level at 50%
table.defaults{roundup=16, grow=150, low=0, high=100}
-- Start filling the table:
local t = {1, 2, 3}
-- ...Many changes in t here...
-- Pack this finalized table (this could cause rehashing so that it will be filled between 25% and 85% and
-- future growth will be by +25%, and reduction will be by 1/.25 =.8 = -20%)
-- no
rounding up of size will occur (size after reduction/growth multiple of 1)
table.def({roundup=1, grow=125, low=25, high=85}, t)
end
table.def(state)
As well:
state
= table.def(nil,t)
(without passing new tuning parameters) could not only return the current tuning parameters of table t, but also some statistics (current effective sizes and number of free nodes in each store: sequential, and hashed) which could be tracked for debugging
The same table.def API could be used to select an algorithm:
table.def{ as = 'default' } to select the default algorithm prefered for the platform
table.def{ as = 'vector'} -- to use an implemetation using unordered vector only, without any hashing, just storing a set of (key,value) pairs
table.def{
as
= 'vector', sort = true } -- same but ordered by the default order (hash values for strings/objects, values for numbers including integers)
table.def{
as
= 'vector', sort = function(a, b) return a < b end } -- would allow storing only strings, numbers, or objects that are comparable with <
table.def{
as
= 'btree'} -- to use a btree, ordered by default using hash values (B-trees require some basic sort order) and page size set to the "roundup" parameter
table.def{
as
= 'btree', sort
= function(a, b) return a < b end } -- would allow storing only strings, numbers, or objects that are comparable with <
And so on... The full syntax would be:
state = table.def(tune, t)
Both parameters are optional (can be nil), "tune" is a table for new parameters to apply, "t" is the table on which to apply this tuning, but if it's nil this applies to the defaults stored in the current environment for new tables created by "{}" constructors or new tables created by any other means (some functions may still create tables with their own tuning, ignoring some or all the hints given in the environment)
And the returned state is a table similar to tune, except it contains a copy of all existing parameters (in the environment or in the specified table), plus statistics about the table (if a table was given in the second parameter)
