Re: C API question

[Eduardo Ochs <eduardoochs@...>]

Hi list,

On Wed, Jan 12, 2011 at 9:59 AM, liam mail <liam.list@googlemail.com> wrote:
>
>>Sure it will! That is why the "user" is a programmer. This is not
>>Office.  We are not in the business of providing ready-to-use solutions
>>to all kinds of things users may want to do. We aim to allow users to do
>>what they need by programming the primitives offered by Lua.
> That is quite correct Roberto, the user is a programmer and one that counts
> from zero. I am asking that these primitives are left alone so that the user
> can choose how to use the library.
>>"The fastest, cheapest, most reliable piece of code is that which
>  >isn't there; design as much out of your code as you design in."
> From what I can tell this is a mis-quote belonging to Gordon Bell yet I
> understand the point you are making, let me give you a quote of my own: Give
> me tools, not shackles.
>
> On 11 January 2011 16:37, Mark Hamburg <mark@grubmah.com> wrote:
>>
>> What's wrong with references? Basically, the issue is that they are
>> dangerous in a number of potentially surprising ways. For example:
>>
>> * They are uncollectable cycles waiting to happen. If you have a userdata
>> that needs to refer to some other Lua object and does so via a reference --
>> a seemingly reasonable use of references -- that opens things up to a cycle
>> that the garbage collector can't collect because the references root the
>> objects in the registry. (The correct solution for these cases is to use the
>> environment table for the referencing userdata.)
>>
>> * They create false matches in multi-universe contexts. Since they are
>> just allocated as integers within a universe, there is no good way to tell
>> that a reference isn't being used in the right universe. It will still
>> likely lead to an object, just the wrong object. Using a light userdata as a
>> key means that you will end up at nil if you try to look for the matching
>> Lua object in the wrong universe. (This could also be addressed by using a
>> global, atomically incremented counter for generating reference id's rather
>> than the existing reference mechanism.)
>>
>> * References also create an initialization order problem with multiple
>> universes if you have data like global tables needed for a C-based module
>> where you try to track their identity via references. Unless all of the
>> universes go through exactly the same initialization sequence, you will
>> probably need different reference indices in the various universes. Again, a
>> light userdata key is a much simpler solution. (This could also be addressed
>> by using a global, atomically incremented counter for generating reference
>> id's rather than the existing reference mechanism though the logic for when
>> to increment the counter would need to be a bit different from the current
>> reference logic.)
>>
>> * If you use the patch to add a global-interpreter-lock to Lua, it won't
>> actually work properly with the reference logic because the reference logic
>> lives on the wrong side of the GIL. If you try to create two references at
>> once, you will probably foul the reference system.
>>
>> Mark
>>
>>
>
> Mark thank you for outlining your concerns, yet I wonder if your main
> problem is "there is no good way to tell that a reference isn't being used
> in the right universe"? We are in C/C++ land and know this instance so well.
>
> What is the defined behaviour of :
> Calling the wrong delete operator on a pointer?
> Using a pointer transfered over the net?
> Indexing out of bounds?
> Using lua_xmove to move data between different universes? (maybe this should
> also be removed)
> Basically using a incorrect handle for the scope?
> I also wonder if your concerns could be appeased if some adjustments were
> made locally to the core? For example using some of the bits of the handle
> to identify which "universe"/scope the handle belongs to maybe then, when in
> a debug build asserting or using some other
> error mechanism to highlight incorrect usage.
> If you feel these problems should be brought to the wider audience and
> documented then maybe they should rather than, as it seems to me, implying
> to a programer that they can not be trusted and should have their toys
> removed from them like a child. If you use tools incorrectly then bad things
> can happen.
> Liam

One suggestion. The people who want changes in the base language
should regard what they get from

  http://www.lua.org/ftp/   and
  http://www.lua.org/work/

as starting points, and they should write their own patches for it,
make them well-documented, widely available, widely tested, widely
_used_, etc, and then refer to what they use as "base Lua-5.x.y with
patches foo-z and bar-w". Then we all, I mean, all who are interested
in this, will be able to run these different, slightly (or
not-so-slightly) incompatible versions of Lua, and compare them...

I think that what many people here fail to understand are the notions
of a "base Lua" and a "starting point". When they ask for changes they
are proposing new, different Luas, usually untested and undocumented,
and more often than not not yet implemented, not even as prototype.
For each proposed change submitted to the list by some bold person a
number of others have been considered by other people, who decided to
not bother the others about their ideas until they were more ripe. The
"base Lua" that the core team produces and makes available is what
they consider the best to be used - as a "starting point" - by
everyone.

  Angry cheers,
    Eduardo Ochs
    eduardoochs@gmail.com
    http://angg.twu.net/