Re: changes in 'require'

[Renato Figueiro Maia <maia@...>]

> I don't see a semantic problem here. "a" is the parent of "a.b". It
> starts making sense to load "a" before "a.b" as soon as you define it 
> as being the standard behaviour.

I guess both cases are semantically reasonable. C packages can hide as 
many implementation modules inside the library and export to Lua only the 
main module API. However script packages may separate core implementation 
in submodules (something like mylib.feature1, mylib.feature2, etc.) and 
leave the main API in the main module (like the mylib). Course you can 
always leave the main module unused and place the main API in mylib.api or 
mylib.sugar or something like that. But I guess placing it in mylib is not 
that weird.

> Semantics apart, the implicit call to require"a" that is generated by a
> call to require"a.b" would be there just to give "a" an oportunity to
> set hooks in case "a.b" doesn't exist in the filesystem. This is a
> common situation for libraries that have several sub-packages and want to
> distribute a single file.

Although I totally agree with you about the importance of a single file 
distribution package, I don't think that imposing some package policy like 
the implicit-parent-load is the best solution. Maybe we could treat the 
module packed in a single dynamic library as a special kind of package 
(just like packages distributed as a compressed archive) and define a new 
loader for this situation. This way it could try to load parent modules
if they are reachable by some different path or file name pattern (like 
lib?.so or bundle/?.so). Is this too expensive?

It would be something like replacing

lib/mylib.so
lib/mylib/feature1.so
shared/mylib/feature2.lua

by

lib/libmylib.so     # Includes mylib, mylib.feature1 and mylib.feature2.
or                  # These packages are better suited for applications 
bundle/mylib.so     # with embedded Lua.

That's just an idea.

Renato Maia.