Re: dream garbage collector

[Edgar Toernig <froese@...>]

Hi,

> John Belmonte wrote:
> >
> > There has been talk about alternate Lua implementations, but what I'd really
> > like to see is just an alternate garbage collector for the TeCGraf
> > implementation.

All alternative garbage collectors I know require read and/or write barriers.
And that either requires hardware support or would slow down Lua a lot.

My opinion (a lot of people will not agree *g*): I would never use a garbage
collected system for hard real-time applications, whatever the designers will
tell me ;-)  And soft real-time may be done with a GC if you know how to
handle that beast :-)  (That may be another good topic for an LTN: How to
use Lua in soft real-time apps.)

Reuben Thomas wrote:
>
> This ties in with my (seemingly ignored!) suggestion about componentizing
> Lua, or alternatively put, specifying some of its internal APIs. The GC API
> was one of the things I suggested formalizing.

About GC: it's very tightly integrated into Lua.  And this tight integration
makes it pretty fast.  You can't really ripp'm apart to use it in some other
applications.  Removing the Lua specific stuff would leave nothing.  Same
for most other parts of Lua.  Or, did I understood you wrong and you want the
opposite - replace parts of Lua with other code - and have formalized inter-
faces do do that?  You could try that.  But I guess it will make Lua bigger
and slower.  Nothing that a lot of people are interested in.  If you are,
go ahead and show that it would be useful ;-)  I'm not convinced yet *g*

You once wrote about regexp for Lua.  Where's the problem?  I see no
problems in replacing Lua's pattern matching with regular expressions.
Are there any pitfalls that require changes to standard Lua?

Ciao, ET.