Re: VM object types (was: TIOBE: Lua in the Top 20)

[Mike Pall <mikelu-0707@...>]

Hi,

Vijay Aswadhati wrote:
> Count my vote as well, perhaps for Lua 6.0? In Ruby strings are
> mutable. Ruby introduces a new type called 'symbol' that are
> interned and used for indexing and comparison [1]. I think such a
> scheme would resolve a couple of issues (at least for me); for
> example I could then use Lua string for mutable binary data buffers
> instead of having to create a new user data.

Ruby's mutable strings create all sorts of difficulties when one
tries to speed it up (e.g. by compiling it). This is a common
symptom of Ruby's excentric semantics: it's slow as molasses.

And ... IMHO mutable strings probably won't have less management
overhead than buffers implemented with userdatas. Yes, I know,
passing userdatas to C APIs expecting plain strings doesn't work
right now. But this can be changed.

David Kastrup wrote:
> Vijay Aswadhati wrote:
> > While we are off topic, let me also include my wish for an integer
> > number type. I hate to maintain special builds of Lua.
> 
> I actually don't see much of a point with that.  Integers convert into
> floats fast, and Lua being an interpreted language not being able to
> make use of register scheduling and other compilation tactiques,
> performance impact on modern architectures is negligible.

This is certainly true on all common, non-embedded platforms as of
today.

> While conceptually integers and floats may be less similar than
> interned and non-interned strings, there is no significant performance
> advantage gained from letting this difference into the language, with
> the single difference from converting large amounts of data structures
> repeatedly and tentatively that might not get processed by Lua at all.

I agree that it shouldn't spill into the language. A sufficiently
advanced VM (probably employing a compiler, not an interpreter)
needs to use type inference, anyway. This allows narrowing of
numbers to integers whenever it's profitable (e.g. for array
indexing).

> What might be more interesting for this kind of enterprise is a
> non-opaque structured user type.  Supporting more diverse basic data
> types in such structures might make the need for them inside of Lua
> itself less compelling.

Funny coincidence ... some random code:

local TValue = typedef.union{
  "n",          "number",
  typedef.struct{              -- Anonymous struct
    typedef.union{             -- Anonymous union
      "gc",     "gcobject",
      "p",      "ptr",
      "i",      "int32",
    }
    "type",     "int32",
  },
}
local Stack = typedef.varray(TValue)

local stack = Stack()
for sp=1,100 do
  stack[sp].type = TYPE.INT    -- Sub-tables are created on-demand
  stack[sp].i = 42
end

typedef.def("ssaref", "short")
local FuncState = typedef.struct{
  ...
  "base",	"int",
  "value",      typedef.varray("ssaref"),
  "varname",    typedef.varray("string"),
  ...
}

local function searchvar(F, name, top)
  for v=F.base-1,1,-1 do
    if F.varname[v] == name then
      return VT.LOCAL, F.value[v]
    end
  end
  ...
end

I think you get the idea ... just pretend ever aggregate is a
table. Standard Lua syntax can then be used to access structs and
arrays. This works even on plain Lua with an emulation layer
(create sub-tables for sub-structures when accessed etc.).

But when compiled, only the raw structures are allocated and all
accesses are translated into efficient machine code. And the GC
traversal is compiled on-demand, too. (No, I'm not there yet ...)

Bye,
     Mike