Re: Custom extensions to Lua

[Glenn Maynard <glenn@...>]

On Wed, Aug 10, 2005 at 02:57:58PM -0500, Rici Lake wrote:
> But the point stands: a reference is a very weird beast.

It's weird to you because you're unfamiliar with them.  I suppose that's just
the nature of "weird", though.  :)  In practice, it's an implementation detail
that you don't have to worry about--a reference doesn't always create a
pointer (more specifically, it can be optimized away); it's the reference
semantics that are important.

> >  int value;
> >  locked<int> value_l = &value; /* initialisation */
> >
> >  value_l = 1; /* lock, assign, unlock */
> >  printf("%d\n", value_l); /* lock, copy, unlock, return copy */
> 
> Well, beauty is in the eye of the beholder :) Many people might prefer 
> something like:
> 
>   synchronized int value;
> 
> although that doesn't give you the option of forgetting to use the 
> locked version :)

This requires specific support from the language itself to implement, and
means the compiler itself has to understand locking, compared to the generic
template solution.

You can't forget anything if you use a template type that doesn't initialize
from a pointer:

  locked<int> value = 1;
  value = 2;

> > While one would be very useful, I do
> >find myself about dubious about whether it's possible to implement it 
> >and
> >still be able to call the result Lua!
> 
> The simple answer is: "no". If you patch the Lua core, the best you can 
> say is that you've created a new language based on the Lua code. (At 
> least, I think the license lets you say that.)

The license doesn't require renaming on modification.  I don't think that's
a very good restriction, especially given that modifying Lua to suit the
particular needs of a project is actively encouraged.  It wouldn't be
very nice to publically fork Lua and not rename it (confusing), but there's
nothing wrong with a project using a heavily modified core and still saying
"we use Lua".

-- 
Glenn Maynard