A few Wild and Wooly Proposals, while we're here (was Re: Feature request: userdata slice)

[Sean Conner <sean@...>]

It was thus said that the Great William Ahern once stated:
> 
> The metatable reference, stored in the unused bits of the type tag, indexes
> an array of pointers to Table objects, right? For 64-bit systems where there
> are fewer significant bits in pointers (e.g. only 48 bits on AMD64 and
> AArch64) the indirection penalty could be avoided by using a uintptr_t for
> the type tag. That would increase the size of TKey, but it could be
> recovered by reordering Node using the same tricks used to pack TKey. AFAICT
> on 64-bit machines Node still wastes 32 bits.

  For all this talk of subtypes and what not, let's rethink things here.  

1) Allow unique metatables for lightuserdata, that also respect __gc.  This
would allow for cheaper creation of datatypes that are managed outside of
Lua.  For my xlib interface [1] it would keep me from having to create full
userdata that's just a pointer to a pointer.  

2) Allow a method to create new literals.  Here me out.  If we do this, and
set up some way of writing code to understand literals, then we can pull
strings out of the core and into an actual module.  Really, the only
difference between a string and a userdata is that there's support for
string literals in core.

  Let's see ... modify the parser such that when it encounters a character
it doesn't understand, or in a context it doesn't make sense, call a
function (supplied by the user) to pick up parsing and return some actual
value.  Perhaps add a metatable to a Lua state with a __parse method:

	function __parse(character,input_function ... um ... )

  Yeah, this could use more work, because there's also code generation to
do.  But it would give Lua a way to extend the syntax in all sorts of fun
ways.

3) Allow the setting of a single breakpoint.  It's always bothered me that
you have to set a hook and get notified *every single time* (function by
function, line by line, cycle by cycle) even if you just want to stop at a
single place.  At least allow a breakpoint at the start of a function.  That
way, the code runs at full speed until the breakpoint.

4) Place all standard Lua functions/modules into a global table called
"lua".  This will prevent the global namespace from being polluted further
as new functions are defined.  

  -spc (I can't let Soni have all the fun here ... [5])

[1]	Not released as it is in no shape for general use.  One, you need to
	know Xlib calls.  Two, it uses a C compiler library [2][3][4] to
	compile some C code on the fly.

[2]	TCC - https://en.wikipedia.org/wiki/Tiny_C_Compiler

[3]	https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.c

[4]	https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.lua

[5]	Some ideas here are serious, some, not so serious.  I'll leave it up
	to the reader to decide which ones are which.