[Prev][Next][Index][Thread]

Re: A basic question: defining modules and libraries

On Mon, 27 Mar 2000, Eric Gouriou wrote:
> Chris Double wrote:
> > Eric Gouriou writes:
> > 
> > > I will never replace/upgrade those libraries individually, so having
> > > them as DLL is useless to me ...
> > 
> > If you're not going to use the reuse the libraries or replace/upgrade
> > them individually, why make them libraries? Why not just make them
> > modules within a library? ...
> 
>  Indeed. And that's exactly why I want the module/library concepts to change,
> because these "define libraries" group my modules in well separated sets of
> functionality. If I were to put all the modules in one or even two libraries,
> the result would be a mess.

Yes, you don't want to have to group more functionality into a library
just for optimsation's sake.  Modules are the unit of interface, libraries
are the unit of *compilation*.  If you look in chapter 2 of the DRM
<http://www.gwydiondylan.org/drm/drm_11.htm> you'll see that the issue of
when libraries are *linked* into a program is left open.  The issue of how
many libraries go into a DLL (or static library) or EXE is entirely up to
the implementation.  As Chris Double has discovered, FD has some support
for combining DLLs -- last I looked, it worked fine, it just didn't have a
good (G)UI yet.

As for increased optimisation, the cited DRM page suggests that optimising
across library boundaries is a no-no but in practice FD lets you do this
(in "Production Mode") and it looks like it's really necessary for good
performance in large apps.  An extension I'd like to see to Dylan is the
addition of type information in the export list of a library.  The actual
implementation types might be more specific than those in the module
exports; the export types would allow the compiler to do more
optimisation while still allowing the implementation to change.  It'd be
half-way between the current "loose" and "tight" binding supported by FD.

>  A typical example is this "Ego-Extensions" library. I want to keep it as a
> library, as most of my projects import it. But I do not want to have it as a
> DLL, as it is mostly a bunch of miscealleanous helper functions/macros that
> should be inlined and/or dead-code eliminated in each of those projects.
> 
>  I gave a bit more thought to what I had proposed Sunday. I believe my proposal
> was inadequate.
>  I realize that the "define module" macro should not be extended. I believe
> that since it is the level where language bindings are exported, modules
> grouping modules (ie modules replacing the current libraries) should be
> forbidden.

This is, I think, why modules don't currently nest.  Also, names of nested
modules might clash with binding names in the same module, which would be
really irritating.

>  So am I happy with the current library/modules macros then ? Not completely.
> There are two improvements I would like to see:
>  A) a naming convention for libraries (maybe along the lines of Java)
>     that would greatly reduce the chances of name collisions.

Note that the DRM says that the mapping from library name (as imported) to
actual source code is implementation-defined:
<http://www.gwydiondylan.org/drm/drm_27.htm>.  I wonder whether the
original designers did this precisely to avoid having to come up with a
way of making everything globally unique.  As long as your particular set
of client libraries can easily be directed to the right set of used
libraries (and as long as you can communicate easily with other people
about which "date" library you mean), who cares what they're called?!

I don't think a language extension is needed to avoid name clashes, rather
an extension to the implementations.  FD currently lets you pick which
project file supplies a library, except for the built-in libraries, but it
could do with a more sophisticated system.  Perhaps the LID file format
(see "Dylan Programming", available in the online help of FD) should be
extended to allow the "global unique" library name to be specified?
And/or perhaps a library or group of libraries could be associated with a
particular name->source mapping table (with a sensible default)?

>  B) A change in the current environments to move away from the idea of
>     1 library  <=> 1 dll/shared library
>  So from the 6/7 first-level libraries in my project, I want:
>   + 1 .DLL made of 2 first-level libraries
>   + 1 .EXE made of 5 first-level libraries
>  And I would like the option to have the .EXE tight-bound to the .DLL
> (ie whenever the .DLL changes, I have to compile a new .EXE, but other
> .EXE can use the same .DLL). 

As I said, I believe FD can do this, but the facilities may not be
documented or easy to get at.

>  A related improvement may be to add versioning information in the
> "define library" or in a new "define deliverable" top-level macro.

Again, this might be better out-of-language, e.g., in LID files.  I only
know enough about versioning to know that it's harder than it seems.
Maybe looking at how existing systems (*nix shared libs, Win32 DLLs,
CORBA, COM) handle it would point us to some "best practice".

> > > Example: I have a library of miscellaneous language extensions I
> > > often use.  How do I name it, so that I can share it with the
> > > community without risks ?

Name it with a fairly obvious one- to three-word name and wait for the
environments to provide a more sophisticated name->library-source mapping
:-)

>  Thanks for your comments and please criticize these new proposal.

I think you have the right idea -- now all we need to do is implement it
;-)

BTW, Nolan, do you feel like your original questions have been answered? 

-- Hugh
Follow-Ups: References: