Re: Ehancement: Projects where source is split over multiple directories

Stefano Novello wrote:
> 
> Here at Parc we have been keeping all our modules in one directory. We 
> are now moving to a tree of directories. Eclipse has some support for 
> this, but things could be improved.
>  
> The biggest problem we have encountered is that because there is a 
> linkage between filename and module, and as there  is a flat name space 
> for modules we are having to enforce a convention as follows:
>  
> 
>     say we have directories a and a/b, then all files in a/b are called
>     a_b_mycode.ecl 
> 
>  
> It would be good if we could call the file simply mycode.ecl even if it 
> contained a module called a_b_mycode.ecl (or maybe using another 
> character because '_' is already used in many names, e.g 'a/b/mycode' 
> (or '.' or whatever)
>  
> If I give the folllowing directive:
>  
> :- lib(a/b/mycode)
>  
> the compiler looks in the library_path, searching for a directory a, 
> then b, then mycode.ecl but it produces an error
>  
> not a module in use_module(library('a/b/mycode'))
>  
> because the module name in mycode.ecl is not mycode, but rather a_b_mycode
>  
> I suggest either removing the link between filename and module, or 
> ideally in the case where a directory is specified in the lib directive, 
> to expect it as a prefix to the module name.

A link between file name and module name exists only for things like use_module/1
and lib/1, which are convenience aggregates of ensure_loaded and import.
When the names don't match, you have to split the file-loading and the
importation aspect by writing

:- ensure_loaded(library('a/b/mycode')).
:- import a_b_mycode.


 > ideally in the case where a directory is specified in the lib directive,
 > to expect it as a prefix to the module name.

I don't think this is desirable because there are usually many alternative
relative and absolute paths the the same file - which one would determine
the module name?  library(blah) is a simply a filespec which first gets
canonicalised into an absolute path name and then the file is loaded using
that.


>  
>  
> A second thing we have noticed is that the interface to add a directory 
> to the library path is slightly inconvenient, it would be good if there 
> was a builtin that did the job of adding a directory to the library
> path,

don't say you want an option to specify the insertion point :-/


 > checking it was not already present,

don't forget that the order in the path may matter...


 > possibly allowing a relative syntax.

Wnat do you mean by that? In what sense is it not allowed now?



> 
> Stefano


-- Joachim