Re: Unpicking require

[Andrew Gierth <andrew@...>]

>>>>> "Gavin" == Gavin Wraith <gavin@wra1th.plus.com> writes:

 Gavin> But I am not sure which sense the dot has in these cases. Is it
 Gavin> 'current directory' or 'filename-extension-introduction'?

My understanding of the code is this:

The intention is that the string passed to "require" should use the '.'
character as the hierarchical separator on all platforms, and therefore
it needs to be replaced by a possibly platform-specific separator when
it would otherwise appear in pathnames or symbol names.

The explicit uses of "." or '.' in loadlib.c are therefore as follows:

  ll_searchpath() (implementation of package.searchpath) uses '.' as the
  default separator to be replaced by LUA_DIRSEP

  findfile() uses '.' as the (fixed) separator to be replaced by
  LUA_DIRSEP

  loadfunc() replaces '.' by LUA_OFSEP (defined as '_') to form a symbol
  name when looking for luaopen_X() in a loadable module

  searcher_Croot() is the searcher for the "all in one" C module format,
  where require "foo.bar.baz" is treated as a request for a symbol
  luaopen_foo_bar_baz() in a C module found by searching in cpath for
  "foo". It therefore uses '.' as the separator to split off that first
  component.

So all of these uses of '.' reflect the (conceptually) hierarchical
structure of the strings passed to require() and are therefore not
dependent in any way on the choice of OS.

The _only_ place where '.' reflects a "file extension" is in the actual
default values of LUA_PATH and LUA_CPATH, and if you change those to
remove the .lua and .so strings, then nothing in the package system
should use file extensions at all.

 Gavin> At present 'require "foo"' works as it should for RISC OS, but
 Gavin> 'require "foo.bar"' does not. I would like all dots in the
 Gavin> argument string to 'require' to be passed through to the
 Gavin> file-loading functions unchanged. I wondered whether the
 Gavin> explicit mention of "." in the loadlib.c sources was the cause
 Gavin> of my problem.

It should not be the cause of your problem.

It seems to me like it should work to define LUA_DIRSEP as "." and
modify the LUA_PATH and LUA_CPATH to conform to your OS's conventions.

-- 
Andrew.