Re: package.config is a string?

[David Manura <dm.lua@...>]

On Thu, Jun 10, 2010 at 11:03 PM, joshua simmons <simmons.44@gmail.com> wrote:
> Is there any great reason for package.config to be a string of elements
> separated by new lines as opposed to a table of individual elements?
> Especially when it contains very useful data like the system's path
> separator.

Having it be a table makes some sense, at the cost of a few extra
objects in memory that might never be used in a program.

The question I have is why package.path and package.cpath are strings
rather than arrays.  If they were arrays--like their analogues in
Python (sys.path), Perl (@INC), and Ruby ($:) and unlike in shell
scripting (PATH), with Tcl perhaps in-between--user code wouldn't have
to worry about parsing and constructing them using the value of
LUA_PATH_SEP (";"), and loadlib.c:pushnexttemplate wouldn't need to
re-parse it on each require.

To append a path, which of these do you prefer?  Which would users
more likely write correctly?  Which is easier to later undo?

  table.insert(package.path, "./mylib/?.lua")
  package.path = package.path .. package.config:sub(3,3) .. "./mylib/?.lua"

Perl, BTW, has a very small convenience notation in the form of a
pragma module [1] that expressed in Lua might look like `import("lib",
"./mylib/?.lua")`, where `import(a,...)` is defined roughly as
`require(a):__import(...)`, which in turn here does
`table.insert(package.path, x)` for each `x` in `...`.  So, to load
./mylib/foo.lua, you would do something like `import("lib",
"./mylib/?.lua"); import("foo")`.  An even shorter form (Ruby example
[2]) would be `lib "./mylib/?.lua"` or just `lib "./mylib"` setting
all ?.lua, ?.so, and ?/init.lua (Steve: suggest to penlight).  Perl 6,
I understand, might also allow the search path to be a lexical so that
changes to it are limited to lexical scope [3].

[1] http://lua-users.org/lists/lua-l/2010-01/msg00456.html
[2] http://blog.ljstech.net/2007/02/ruby-lib-path-manipulations.html
[3] http://irclog.perlgeek.de/perl6/2010-06-12#i_2426382