Re: table library changes (was Re: table.new in 5.3?)

["John Hind" <john.hind@...>]

> Date: Wed, 27 Nov 2013 17:16:02 +0000
> From: Justin Cormack <justin@specialbusservice.com>
> Subject: Re: table library changes (was Re: table.new in 5.3?)

> Interesting, but shouldn't the stuff that can be implemented in Lua be
> removed form the language? ;-) Adding more C support for things does
> sounds good though.

Yes, this is the crux of my argument.

1. There are currently some fairly large chunks of C code in the standard libraries which are accessible from Lua but not via the C API. The string library is probably the largest culprit here, but sort in the table library is (may be) another example.

2. "The Language" could include standard libraries implemented in Lua. Minimising the C code makes it easier to evolve the language administratively. Code shipped in Lua can be declared to be part of the language standard, compatibility code which will be removed in future, or just example code for illustrative purposes. Compatibility code in Lua can easily be adopted by people who do not want to lose the feature being deprecated.

3. So long as enabling mechanisms are in the language, just because something is useful does not mean it needs to be part of the language. Minimalism is a worthwhile goal. If you like 'ipairs', then by all means implement it yourself (in Lua), it is not hard! The experience may encourage you to use iterator factories more widely.

4. Benchmarks should not have the last word between C and Lua - if you take that position, why use Lua at all? If something widely used is orders of magnitude less efficient in Lua, or scales badly, then that is a good argument, but we should be ready to accept a few percent less efficient with the same scaling law.

- John


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com