[ANNOUNCE] Lua 4.1 (work4)

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCE] Lua 4.1 (work4)

Luiz Henrique de Figueiredo
A new snapshot of Lua 4.1 (work) is now available at
        http://www.tecgraf.puc-rio.br/lua/work/lua-4.1-work4.tar.gz

This version contains several changes mentioned in the list: core co-routines
(aka, the yield patch), dynamic stacks, new generalized "for" statement
("for k,v in f do .. end" calls to return k and v if f is a function),
simplified syntax for table constructors (you can freely mix items in the
"list part" with item in the "table part", as in {1,x=10,2,y=20}; ';' are gone, 
but still accepted for compatibility), eventtable has been renamed metatable,
lua.c supports incomplete statements, and probably more that I forget now ;-)

The manual has been partially updated is available at
        http://www.tecgraf.puc-rio.br/lua/work/refman-4.1-work4.pdf
        http://www.tecgraf.puc-rio.br/lua/work/refman-4.1-work4.ps.gz
It does not mention co-routines yet but it does describe the new for and
the new syntax for table constructors.

Of course, none of these changes is definitive. This is simply a work version
that is being made available so that you can experiment with it and send us
your feedback.

Enjoy.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

John Belmonte-2
lhf wrote:
new generalized "for" statement
("for k,v in f do .. end" calls to return k and v if f is a function)


Hmmm I had just added that to my warts list, which is almost exhausted. Lua used to be easy to pick on, but now it's getting more challenging. I'm about ready to give up :-).


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

RLak
In reply to this post by Luiz Henrique de Figueiredo
> This version contains several changes mentioned in the list: core
co-routines
> (aka, the yield patch), dynamic stacks, new generalized "for" statement
> ("for k,v in f do .. end" calls to return k and v if f is a function),

Ooooh, this is so *almost* what I want. Can't we please, please have a next
tagmethod to go with it? It would be soooo simple... (Yes, I know I can
write for k, v in metatable(object).next do ..., but that means that I need
to either write that always or know whether or not object is a regular
table; that is not good for code maintainability.)

> simplified syntax for table constructors (you can freely mix items in the
> "list part" with item in the "table part", as in {1,x=10,2,y=20}; ';' are
gone,
> but still accepted for compatibility), eventtable has been renamed
metatable,
> lua.c supports incomplete statements, and probably more that I forget now
;-)

Also very cool! Thanks, guys.

Rici



Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Steve Dekorte-4

On Friday, February 15, 2002, at 07:34  AM, [hidden email] wrote:
Ooooh, this is so *almost* what I want. Can't we please, please have a next
tagmethod to go with it? It would be soooo simple... (Yes, I know I can
write for k, v in metatable(object).next do ..., but that means that I need
to either write that always or know whether or not object is a regular
table; that is not good for code maintainability.)

A getn() tagmethod would be really nice too. Basically, it would be nice to have userdata capable of replacing any value in Lua(particularly a table value). This way userdata for a database (like tdbm) can replace a table or a userdata that handles arbitrary length numbers could replace a number, etc.

Steve



Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Thomas Wrensch-2
Steve,

If you like, it's easy enough to modify Lua to allow a getn tag
method. Here's a Lua implementation:

    _getn = getn  -- Save old getn function
    getn = function(obj)
        local mt = metatable(obj)
        if mt~=nil then
            local f=mt.getn
            if f~=nil then
                return f(obj)
            end
        end
        return _getn(obj)
    end

(Note that the above can be made shorter by using the "or" idiom.)

Now you can use it just like there was a built-in "getn" tag:

    MyMetaTable = {}
    MyMetaTable.get = function(obj) return 1 end -- always n=1

    t = {}
    print(getn(t))   -- prints 0
    metatable(t,MyMetaTable)
    print(getn(t))   -- prints 1

Note that this works fine with userdata too, since the modified
getn function does not check to make sure its argument is a 
table.

A C implementation would be faster of course.

Hope that helps.

  - Tom Wrensch

On Fri, 15 Feb 2002, Steve Dekorte wrote:

> 
> On Friday, February 15, 2002, at 07:34  AM, [hidden email] wrote:
> > Ooooh, this is so *almost* what I want. Can't we please, please have a 
> > next
> > tagmethod to go with it? It would be soooo simple... (Yes, I know I can
> > write for k, v in metatable(object).next do ..., but that means that I 
> > need
> > to either write that always or know whether or not object is a regular
> > table; that is not good for code maintainability.)
> 
> A getn() tagmethod would be really nice too. Basically, it would be nice 
> to have userdata capable of replacing any value in Lua(particularly a 
> table value). This way userdata for a  database (like tdbm) can replace 
> a table or a userdata that handles arbitrary length numbers could 
> replace a number, etc.
> 
> Steve
> 
> 
> 


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Steve Dekorte-4

On Saturday, February 16, 2002, at 03:50  PM, Tom Wrensch wrote:
If you like, it's easy enough to modify Lua to allow a getn tag
method. Here's a Lua implementation:

Thanks, this is a good idea and I considered it. Unfortunately there's a problem when it come to sharing. For example, if I implemented a getn() as above for the tdbm binding and someone else implemented their own getn() for another binding and you tried to use both libs at the same time, one would over write the other, breaking it. Likewise with next().

Steve



Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

John D. Ramsdell-3
In reply to this post by Luiz Henrique de Figueiredo
The Lua 4.1 (work4) source distribution fails to use conventions for
makefiles and configuration used by the open source community.  Please
embrace this community by using autoconf to generate your config
script, and create a makefile than follows the usual conventions for
the all, clean, install, and uninstall targets.  Make it so that the
INSTALL document is nothing other than the file included by all
applications that follow the conventions.  Please make it easy to
install your program.

> http://www.tecgraf.puc-rio.br/lua/work/refman-4.1-work4.pdf

This document cannot be displayed xpdf on RedHat Linux 7.1 due to the
use of Type 3 fonts.

John

-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Daniel Silverstone
On Mon, Feb 18, 2002 at 07:45:45AM -0500, John D. Ramsdell wrote:
> The Lua 4.1 (work4) source distribution fails to use conventions for
> makefiles and configuration used by the open source community.  Please
> embrace this community by using autoconf to generate your config
> script, and create a makefile than follows the usual conventions for
> the all, clean, install, and uninstall targets.  Make it so that the
> INSTALL document is nothing other than the file included by all
> applications that follow the conventions.  Please make it easy to
> install your program.

Unfortunately the "Open Source Community" fails to accept that sometimes
people just plain don't like autoconf etc.

For example: I was able to automatically build lua (with the makefile
supplied, almost unchanged) on several architectures which are not UNIXes

Perhaps you would like to explain to us how autoconf helps portability to
these platforms.

Autoconf is designed to help programs cope with portability between slightly
posix systems -- since Lua is entirely ANSI C -- this kinda becomes
irrelevant.

Altering the makefiles to provide all, clean, install and uninstall targets
might be worthwhile, but in the end anyone who wants to use Lua will use it
in whatever way they see fit.

For most people, Lua will be installed via a package manager if they are
unable to cope with downloading it and installing it themselves.

Try looking at some of the reasons for why Lua chose simple Makefiles before
jumping into an attack on those choices.

Lua /is/ easy to install, perhaps not for people who don't know what they're
doing when they install software which isn't pre-packaged, but then again,
is that such a bad thing?

Regards,

Daniel Silverstone -- Packager in charge of Debian GNU/Linux Lua packages

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
Always leave room to add an explanation if it doesn't work out.

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Erik Hougaard
----- Original Message -----
> > The Lua 4.1 (work4) source distribution fails to use conventions for
> > makefiles and configuration used by the open source community.  Please

Hmm... So the "Open source community" is just Unix/Posix ?  I dont think so
...

But the main problem is still, that Lua is two different things to different
people. We have the script guys who just want to download/install/use, and
then we have the embedded people (including my self) who embeds Lua into all
sort of different thing and we dont care about makefiles cause we need it to
be part of our own build system, so we are most more interested in keeping
Lua 100% ANSI-C without tons of preprocessor defines that would collide with
the application that we embed Lua into.

I still think that Lua should be splitted up into two things, a library and
a script engine. And maybe the script engine should be maintained outside
tecgraf. Remember that the current LUA.C started out as a example of a lua
application.

/Erik


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

John D. Ramsdell-3
In reply to this post by Daniel Silverstone
Daniel Silverstone <[hidden email]> writes:

> Lua /is/ easy to install, perhaps not for people who don't know what they're
> doing when they install software which isn't pre-packaged, but then again,
> is that such a bad thing?

This is false.  Lua is not easy to install.  For autoconfig'ed
systems, one simply types:

$ ./configure
$ make
$ make install

There are no instructions to read, and the process can be automated.
This is what it means for software to be easily installed.

The current Lua install method requires that one edit it's makefile.
The makefile has it's own conventions that are different from every
other package.  It's a waste of time to ask programmers to go through
this process.

Autoconf solved this problem a long time ago.  It's well tested
software that is accepted by the community.  There is a reason so many
people use it.

John


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

John D. Ramsdell-3
In reply to this post by Erik Hougaard
[hidden email] (Erik Hougaard) writes:

> But the main problem is still, that Lua is two different things to different
> people. We have the script guys who just want to download/install/use, and
> then we have the embedded people (including my self) who embeds Lua into all
> sort of different thing and we dont care about makefiles cause we need it to
> be part of our own build system, so we are most more interested in keeping
> Lua 100% ANSI-C without tons of preprocessor defines that would collide with
> the application that we embed Lua into.

For embedded people, shouldn't it be possible that a Lua header file
and a shared library are placed in some appropriate public places.
Embedded usages of Lua compile source files using the interface
declared by the public header file, and then link in the shared
library at runtime.  In this model, the script engine is just another
consumer of the shared library.  It is compiled by including the
public header file, and it links to the shared library at run time.
It's no different than any other embedded user of the library.

In any event, the use of autoconf could be easily used to create this
setup.  Building and installing shared libaries is well supported.
There should be no conflict between embedded and scripting Lua users.
Embedded poeple should be able to use Lua as a shared library if that
best suits their needs.  Or they may simply want to copy the sources
into there source tree.  Whatever works...

John

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>This is false.  Lua is not easy to install.  For autoconfig'ed
>systems, one simply types:
>
>$ ./configure
>$ make
>$ make install

In Lua, in a Unix system that has gcc, you simply type "make install"!

>The current Lua install method requires that one edit it's makefile.

Only if you want to do something other than the default. And it's a config file,
not the Makefile. As far as I can tell, the Makefile is pretty standard.
If not, I welcome suggestion on making the Makefiles more standard and portable.

Lua is 100% ANSI C. You only need an ANSI C compiler to build it.
There's no need for Autoconf because it does not depend on the OS.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

yphilho
In reply to this post by John D. Ramsdell-3
(Answering via groups.yahoo.com, since I seems to miss the latest 
messages. Mmm, it is just slow, I received Daniel's response to the 
original message of John before the first message of this thread...)

--- In lua-l@y..., ramsdell@l... (John D. Ramsdell) wrote:
> Daniel Silverstone <dsilvers@d...> writes:
> 
> > Lua /is/ easy to install, perhaps not for people who don't know 
what they're
> > doing when they install software which isn't pre-packaged, but 
then again,
> > is that such a bad thing?
> 
> This is false.  Lua is not easy to install.  For autoconfig'ed
> systems, one simply types:
> 
> $ ./configure
> $ make
> $ make install
> 
> There are no instructions to read, and the process can be automated.
> This is what it means for software to be easily installed.

As you say: "For autoconfig'ed systems". I am no specialist, but I 
think that for systems that doesn't have /bin/sh (Windows, perhaps 
others like BeOS or MacOS), it doesn't work.
And from what I see in the libraries I downloaded (eg. cURL, 
ImageMagick, PCRE), configure files sum up to hundred of KBs! For 
ImageMagick, configure file alone = 420KB! That's quite big for such 
a result.

> The current Lua install method requires that one edit it's makefile.
> The makefile has it's own conventions that are different from every
> other package.  It's a waste of time to ask programmers to go 
through
> this process.
> 
> Autoconf solved this problem a long time ago.  It's well tested
> software that is accepted by the community.  There is a reason so 
many
> people use it.
> 
> John

Well, the makefile of Lua is quite stable, so why don't you create 
and distribute separately an autoconf package for Lua? It makes a 
double download, but at least it won't bloat the official 
distribution for those which don't need/cannot use these files.

Regards.


rje
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

rje
In reply to this post by John D. Ramsdell-3
On Mon, Feb 18, 2002 at 08:39:26AM -0500, John D. Ramsdell wrote:
> Daniel Silverstone <[hidden email]> writes:
> 
> > Lua /is/ easy to install, perhaps not for people who don't know what they're
> > doing when they install software which isn't pre-packaged, but then again,
> > is that such a bad thing?
> 
> This is false.  Lua is not easy to install.  For autoconfig'ed
> systems, one simply types:
> 
> $ ./configure
> $ make
> $ make install

autoconf makes things easier to install on Unix based systems only.
autoconf becomes a complete pain the *instant* you want to do anything with
an application under something that isn't supported by autoconf.  For
example, success with Windows and RISC OS is extremly limited.

<snip>

> The current Lua install method requires that one edit it's makefile.
> The makefile has it's own conventions that are different from every
> other package.  It's a waste of time to ask programmers to go through
> this process.

Considering lua is written in 100% ANSI C, asking programmers to fudge
around the uglyness that autoconf involves to run it on something other than
a Unix (such as Windows, RISC OS, embedded OSes) is far more work that
tweaking a Makefile.

> Autoconf solved this problem a long time ago.  It's well tested
> software that is accepted by the community.  There is a reason so many
> people use it.

I'm yet to see any problem solved by autoconf other than making it slightly
easier for people to compile programs on a Unix or similar OS.  It doesn't
aid the majority of users in this world from compiling or installing it at
all, in fact it hinders it.  One of the reasons I fell in love with Lua so
quickly is that you don't have to faff around with autoconf.

(autoconf also has lots of small problems even working on real Unices, such
as RISC iX, for the simple reason that the OS' name has a space in it...)

-- 
Rob Kendrick - http://www.digital-scurf.org/
You will hear good news from one you thought unfriendly to you.

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Kenneth Gangstoe-2
In reply to this post by John D. Ramsdell-3
Quoting John D. Ramsdell ([hidden email]):
> Daniel Silverstone <[hidden email]> writes:
> 
> > Lua /is/ easy to install, perhaps not for people who don't know what they're
> > doing when they install software which isn't pre-packaged, but then again,
> > is that such a bad thing?
> 
> This is false.  Lua is not easy to install.  For autoconfig'ed
> systems, one simply types:
> 
> $ ./configure
> $ make
> $ make install
> 
> There are no instructions to read, and the process can be automated.
> This is what it means for software to be easily installed.
> 
> The current Lua install method requires that one edit it's makefile.
> The makefile has it's own conventions that are different from every
> other package.  It's a waste of time to ask programmers to go through
> this process.
> 
> Autoconf solved this problem a long time ago.  It's well tested
> software that is accepted by the community.  There is a reason so many
> people use it.

The reason so many use it, is that so many use it :) It doesn't mean its good.
Actually, most people I talk to think its total crap system to support alot
of broken unix'es, but they still use it since its "standard".

- Kenneth

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Dave Smith
In reply to this post by Luiz Henrique de Figueiredo
Could I suggest that you reconsider your approach here
to be less confrontational. As a number of people have
(politely) pointed out there are a number of good
reasons why the build/install system is setup as it is
- most people seem happy with this (or the packaged
alternatives for most major OSs).

As has been stated autoconf is by no means a panacea
given the non-UNIX usage of Lua (and ignoring the fact
that even on UNIX autoconf is a braindead nightmare). 

Continuing to demand that Lua be changed to suit your
preferences seems rude and ungrateful - particularly
as nobody is forcing you to use Lua or has any stake
in you doing so.

If you want to create an autoconf script for your own
use and make this available I am sure that nobody
would object however.

DS

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

Reply | Threaded
Open this post in threaded view
|

autoconf (Re: [ANNOUNCE] Lua 4.1 (work4))

Jay Carlson
In reply to this post by Luiz Henrique de Figueiredo

On Monday, February 18, 2002, at 09:26 AM, Luiz Henrique de Figueiredo wrote:

[moved to top]
> Lua is 100% ANSI C. You only need an ANSI C compiler to build it.
> There's no need for Autoconf because it does not depend on the OS.

Lua is not 100% ANSI C. It's configurable to build that way, but the use of popen and the support for readline allow minor extensions at the cost of being 99.44% ANSI C. :-) But the 100% ANSI option is the default, and I agree with it.

Also, autoconf is not just about discovering the runtime environment (which is 99.44% ANSI in Lua's case.) autoconf is also about discovering the build-time environment---what compiler should I use, what arguments do I need to use to link in the libraries for this function, and so on.

That being said, I think the "read, understand, edit-by-hand" config file should not go away. There are enough non-POSIX build systems out there that "autoconf or die" is a silly idea. Yes, I use cygwin, but sometimes I use Visual C++ too, and autoconf won't help me at all there.

fltk is an example of a package that supports both configuration styles; autoconf for systems that support it, hand-edit for those that don't.

This is false.  Lua is not easy to install.  For autoconfig'ed
systems, one simply types:

$ ./configure
$ make
$ make install

In Lua, in a Unix system that has gcc, you simply type "make install"!

The current Lua install method requires that one edit it's makefile.

Only if you want to do something other than the default. And it's a config file,
not the Makefile. As far as I can tell, the Makefile is pretty standard.
If not, I welcome suggestion on making the Makefiles more standard and portable.

The Makefile looks good; it moves its configuration options to config, which is a good practice, but it's still part of the configuration.

Lemme enumerate what config does. I'll flag those that autoconf would assist with.

Chooses number format.  Not something people do lightly.

Chooses whether to build popen into liblualib. (Incidentally, popen is defined in -D_POSIX_C_SOURCE=2, so if you want full warningless compiles, you should set that instead of _POSIX_SOURCE if you have popen on. But it's only one function prototype.) [autoconf would detect popen, and could try flags to get the prototype.]

Sets compiler explicitly. Is there a good reason not to use make's builtin CC definition? [autoconf picks up the CC definition from either the environment or the site config.]

...oh, and sets warning options, which are compiler dependent. So if you didn't need compiler-dependent warnings you could avoid setting CC. [autoconf would allow supplying the proper options to CC if CC is known, otherwise falling back on the empty string.]

Sets optimization options. In theory, compiler-dependent, but most every compiler supports -O2. [Again, autoconf can probe for the availability of particular optimization options.]

Sets LDFLAGS.

Sets _POSIX_SOURCE. Note that this has two functions. First, it tells the system to provide function prototypes defined by POSIX (above what you get with ANSI); second, it turns on an internal prototype in lua.c. [Slam dunk for autoconf.]

Lists libraries needed to link lua.c and luac.c. [autoconf can determine what libraries are needed to get a successful link given a list of functions.]

Allows configuration of readline support in lua.c. Defines what libraries need to be linked in that case. [Obvious use of autoconf; if the user asks for this with --enable-readline, autoconf can detect whether readline is actually available and what libraries need to be linked.

Defines AR, RANLIB, and STRIP.  [autoconf does this for you as well.]

Defines multiple variables to control installation destination. (Note that for man pages, /share/man is more correct on many systems than /man.) [autoconf has excellent support for configuring installation.]

Sets the tool used to install data and binaries. [Most people use autoconf's "look for BSD install, fall back to cp" rules.]

autoconf makes the life of people doing cross compiles much easier, as well as those who have standard configuration options site-wide.

Jay


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

John D. Ramsdell-3
In reply to this post by Luiz Henrique de Figueiredo
My request to employ autoconf in Lua was simply just that, a request.
I am hoping that the lua developers will embrace accepted open source
practice.  It sounds like the answer is no, but before I drop the
issue, please let me add just one more point to the discussion.

Luiz Henrique de Figueiredo <[hidden email]> writes:

> In Lua, in a Unix system that has gcc, you simply type "make install"!
> 
> >The current Lua install method requires that one edit it's makefile.
> 
> Only if you want to do something other than the default. And it's a
> config file, not the Makefile. As far as I can tell, the Makefile is
> pretty standard.  If not, I welcome suggestion on making the
> Makefiles more standard and portable.

The point of using autoconf is that it can be used to automatically
generate the content of the config file.  There is no need to ask that
humans edit the config file.  Let autoconf probe the environment and
then write the config file. 

> Lua is 100% ANSI C. You only need an ANSI C compiler to build it.
> There's no need for Autoconf because it does not depend on the OS.

Just because Lua is 100% ANSI C does not imply its build process is
does not depend on the OS.  This is the reason you have a config file.

John

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Reuben Thomas
> > Lua is 100% ANSI C. You only need an ANSI C compiler to build it.
> > There's no need for Autoconf because it does not depend on the OS.
>
> Just because Lua is 100% ANSI C does not imply its build process is
> does not depend on the OS.  This is the reason you have a config file.

To be precise, it depends on the environment (build tools &c.), not so
much the OS (the one or two non-ANSI functions).

The fact that it's very nearly 100% ANSI does mean that one should look
with suspicion on using a definitely non-portable tool like autoconf (make
is not much better, admittedly).

To my mind, an autoconf script is something that should go in a "Lua
distribution" of the sort I've been discussing recently, rather than
vanilla Lua.

Talking about "embracing open source standards" is missing the point: it's
open source, they're giving it away, they can do what they like. Not using
autoconf does not make the Lua team even quixotic, let alone bad. Other
programs with similar goals don't use autoconf, e.g. bzip2, which
nonetheless is widely used in open source-based systems.

-- 
http://sc3d.org/rrt/ | competent, a.  underpromoted


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Thomas Wrensch-2
In reply to this post by Steve Dekorte-4
Steve,

A very good point. If that's a problem (and it will be for many
people) then maybe this is something that could be moved to the "standard
user library" that seems to be slowly being developed. That would provide
a reasonable level of standardization for handling new "tags" implemented
this way, allowing the Lua masters time to decide which tags are most
appropriate to move into the language.

  - Tom Wrensch

On Sat, 16 Feb 2002, Steve Dekorte wrote:

> 
> On Saturday, February 16, 2002, at 03:50  PM, Tom Wrensch wrote:
> > If you like, it's easy enough to modify Lua to allow a getn tag
> > method. Here's a Lua implementation:
> 
> Thanks, this is a good idea and I considered it. Unfortunately there's a 
> problem when it come to sharing. For example, if I implemented a getn() 
> as above for the tdbm binding and someone else implemented their own 
> getn() for another binding and you tried to use both libs at the same 
> time, one would over write the other, breaking it. Likewise with next().
> 
> Steve
> 
> 
> 


12