Re: [Lua-users-stdlib] Contribution

[Jamie W. <j...@jm...>]

On Monday 02 February 2004 09:38, Reuben Thomas wrote:
> > I can imagine wanting a linked list, and then wanting the standard
> > operations on it.
>
> But tables give you those operations and with lower complexity. What's the
> problem?

Linked lists have faster inserts and deletes, and you can use tail() 
efficiently for nice recursive algorithms (I know you could just pass a start 
index around, but it's not as neat).

> > Everything's an untyped reference in Lua so all tables are monomorphic,
>
> Strings? Numbers? Threads? Functions? Booleans?

I meant that tables are monomorphic containers. All those types you list are 
still accessed using untyped references.

> I'd forgotten I had the set in a set member, and came up against that last
> night with some old code. This will be fixed.

It needs to be there though if you're going to do OOP, otherwise you might 
have a set containing the name of one of your methods.

> Depends what for. I want to leave the core tables stuff in the library as
> simple as possible so that everyone can use it in even their most basic
> scripts. That's certainly the only way the Lua authors are likely to get
> interested. The special-purpose stuff like getopt and parsers can quite
> happily be more OO: it's the sort of thing that attracts users because it
> already does most of their job, but only if they're doing that specific
> thing.

With the current Lua table stuff, one can set { __index = table } for a vector 
and have nice OO operations like t:getn(), and that's great, except that it's 
unreliable since any vectors a function receives need not have __index set. 
My problem is that it seems clear the the Lua authors intended the OO 
behaviour to be available for vectors, but failed to follow through. That 
makes me unsure as to what exactly the 'Lua way' is supposed to be.

What I'd like to see in the language I think is a) a way to set the default 
metatable for 'arg', b) distinguished __index and __method, and c) a way to 
type function parameters, so that we can write code something like this, but 
hopefully more efficient:

function foobar(x : Vector)
	-- Above line equivalent to writing 'x = Vector(x)' here
	-- can rely on x:map() working in here
end

Vector = setmetatable({
		new = function(self, ...)
			return setmetatable(arg, {
				__method = self,
				is_Vector = true })
			end
		map = function(v,f) -- etc.
	}, {
		__call = function(self, v)
			local m = getmetatable(v)
			if not m then
				-- This part optional
				-- Could just insist on 'proper' vectors
				assert(type(v) == "table", "...")
				-- Maybe do some checking to make sure that
				-- v looks like a Vector here.
				return setmetatable({}, {
					__index = v,
					__newindex = v,
					__method = self,
					is_Vector = true })
			end
			-- Any object can still behave like a vector by setting is_Vector
			assert(m.is_Vector, "...")
			return v
		end
	})

The distinguished __method has more general applications, and I think the 
generality of that typing scheme (the 'type' can be any functor) fits the Lua 
philosophy.

> I would really like to see proof that map being coded in C makes a
> difference: the amount of Lua code in it is tiny, and surely the vast
> majority of the time will be spent in the table construction even if it's
> not spent in the function.

Your map probably wouldn't be much different, but anything variadic can 
probably become noticeably faster in C.

> Peversely, it does seem almost more likely that the Lua team will look
> kindly on new C code than new Lua code...which is silly, because the
> maintenance cost of Lua code from version to version is so much lower.

Most of the current Lua library functions are not implementable in Lua, or at 
least not efficiently, and that could be the criteria for any further 
additions.

> How about "copy" (for shallow) and "clone" (for deep)?

Clone certainly sounds like a deep copy to me. Not so sure about copy though. 
I think that could mean either, as evidenced by the terms deep and shallow 
copy.

 -- Jamie Webb