This page reviews Lua modules. One goal is to identify one or more sets of quasi-official/important modules that are recommended over others as best practices and for inclusion in Lua standard libraries and Lua distributions (e.g. LuaForWindows?).
Function Categories
These are the areas of functions that are important for standard libraries and distributions to cover, along with modules that best satisfy those needs.
Key: [W] = included in LuaForWindows?. [K] = included in Kepler[1]. [A] = ANSI C. [L] = pure Lua implementation (no C)
- Basic data structures, utility functions
- PenLight?[2]? [L mostly] - table/list/set/map operations, string functions, utility functions, I/O utility functions, functional programming, list comprehensions, file path parsing, command line parsing (see also StandardLibraries) - (good docs, but design quite in flux as as 200906).
- OS / System
- Note: some of these require platform support in C.
- file system manipulation: FileSystemOperations
- file path name manipulation (e.g. like boost filesystem [3]) - see FileSystemOperations
- Command-line parsing (CommandLineParsing - which one?)
- Date/time - which one?
- networking/sockets: LuaSocket? [W|K] - quality=?, usefulness=high (others?)
- Multitasking (MultiTasking - which one?)
- OS specific (e.g. POSIX / Win32) - which ones? lposix [4] ?
- Foreign-function interfaces (FFI) - these can interface to non-Lua code, much extending the capabilities of Lua
- Note: these typically require platform support in C.
- Lua->C: Alien [W]
- Lua->Python: LunaticPython [W-planned] (note: currently LGPL)
- Lua->Java: (which one?)
- Windows-specific:
- Parsing / Serialization / Formats
- Note: all of these can probably be implemented in both pure Lua [L] or (for possibly greater efficiency) ANSI C [A].
- bitwise operations (BitwiseOperators - probably Bit
- struct manipulation - StructurePacking
- Unicode (which one?)
- PEG: LPeg [W|A] - quality=high, usefulness=high - applications: lexing/parsing beyond regular expressions
- regular expression library (lrexlib? MIT licensed but uses BSD regex libraries (PCRE or Oniguruma) or POSIX regex.h (license?)) concerns: [12]. is this as needed given LPeg?)
- XML parsing (which one? LuaExpat?? [W|K] MIT license) - see LuaXml
- JSON parsing - JsonModules
- CSV parsing? (which one?) - LuaCsv
- Lua parsing: Allowing Lua to parse itself has theoretical as well as practical importance, including building compilers and source analyzers. There are a number of distinct approaches:
- The gg and mlp parsing modules contained in MetaLua. [L] mlp parses Lua source (optionally with syntax extensions) to an AST. It is built upon gg, which can parse more general grammars (not just Lua) and can also be useful. The lexer is based on Yueliang. A number of Lua source analysis tools and compiler reimplementations use mlp. The AST design/interface is well thought out and is used as well in full MetaLua applications. Testing has been performed by a number of users. It is implemented in Lua, which is convenient but unlikely makes the fastest parser.
- Leg [5] may be another candidate. Leg is used in the Shake [6] unit testing framework. Leg is based on LPeg (see above), so it should be efficient. Leg doesn't appear to generate a well defined AST (like MetaLua). A nice extension would be for it to generate MetaLua style ASTs for consistency (this might be done in the similarish LPeg parser contained in [LuaFish]).
- Another approach is to use Lua's own lexer code (llex.c), such as with lhf's libraries [7][8].
- For others, see LuaGrammar.
- Encoding
- Compression/Decompression - see CompressionAndArchiving
- ZIP file read/write (LuaZip?? [W|K] - read-only ZIP. MIT licensed but uses zzpiblib [zziplib.sourceforge.net] library, which is dual MPL/LGPL licensed) - applications: extracting LuaRocks archives, system administration (e.g. compressing log files / extracting archives), compressed virtual file systems (e.g. perhaps modules stored in a ZIP archive and loaded with a custom searcher function), reading ZIP-based formats (e.g. OpenOffice? docs).
- zlib read/write (LuaZlib?? [/luazlib/]) - applications [9])
- Lua object persistence - PlutoLibrary
- Cryptographic - CryptographyStuff
- Note: all of these can probably be implemented in both pure Lua [L] or (for possibly greater efficiency) ANSI C [A].
- Digest
- MD5: (MD5? [W|K] [A-C99?] MIT licensed. supports DES too) - applications: validating archive integrity (e.g. LuaRocks), general cryptographic hashing for security (e.g. storing password hashes) and web apps.
- SHA1, CRC32 - which ones?
- UniversallyUniqueIdentifiers - UUID generation
- Testing/Debugging/Profiling
- Module deployment - LuaRocks [W-planned]
- Packaging - BinToCee or related modules? srlua [10]?
- Graphics/Multimedia - second tier
- Database - second tier
- SQL: LuaSQL [W] - quality=?, usefulness=med
- Web Applications - second tier
- Numerical/math - second tier
- (LibrariesAndBindings - which ones?)
- matrix library - There is LuaMatrix [L] and then is [Numeric Lua] (C/Fortan)
- big number support (this may be first tier) - which one?
- special functions: bessel, elliptic, erf, ... - which one?
- statistical?
- Other - second tier?
Module Levels
Modules may be ranked into multiple levels of importance or applicability. A distribution might include the lower levels but not fully support the higher levels.
- Zeroth tier - Lua standard library and any other modules implemented in ANSI C
- First tier - these modules should be highly useful, have high quality, have a small size, have a permissive license, and work on a reasonably large number of platforms (including POSIX and Win32)
- Second tier - these may be essential only to certain classes of applications and have a larger size
Characteristics Measured
These qualities are useful for determining the appropriateness of including modules in standard libraries and distributions.
- Usefulness - A module is highly useful if it is needed in a large, diverse set of applications. For example, a large number of programs require non-ANSI file system operations or bitwise manipulation operations. Note: a module could still be quite useful even if it has low implementation quality (defined below).
- Implementation quality - This pertains to good interface design and low number of bugs (extensive test suite). Note: certain distributions might make quality assurance guarantees, such as for critical applications.
- Packaging quality - This includes other non-functional quality areas: documentation, LuaRocks spec inclusion, build system, etc.
- License - e.g. MIT or otherwise. Note: certain distributions might restrict themselves to only MIT licenses (compatible with Lua), while others might allow or disallow open source or proprietary libraries (e.g. debian free/nonfree [11])
- Dependencies - OS dependencies, dependence on system libraries, compiler dependencies (e.g. GCC/MSVC), and implementation language (e.g. pure Lua or C). Note: a Windows distribution would not include Linux-specific modules, and certain distributions might restrict themselves to pure Lua modules or ANSI C modules.
- Size - some things like GUI toolkits may bloat some distributions too much. Increased size also increases difficulty to ensure quality/testing. A small library that does one thing well is preferred over a large library that does many things ok.
See Also
- LuaDistributions - distributions may include many of these modules
- StandardLibraries - other efforts at Lua library standardization
- Other standard libraries (those useful for comparison)
RecentChanges · preferences
edit · history
Last edited February 22, 2011 1:48 am GMT (diff)
