Re: A basic question: defining modules and libraries

To: info-dylan@ai.mit.edu
Subject: Re: A basic question: defining modules and libraries
From: Eric Gouriou <eric_gouriou@cup.hp.com>
Date: Wed, 29 Mar 2000 02:00:03 -0500 (EST)
Organization: Hewlett-Packard Company
References: <87u2hxct70.fsf@ethereal.dyndns.org> <brucehoult-2403001218020001@bruce.bgh> <slrn8dli23.fmr.neelk@brick.cswv.com> <m3hfdwwh0n.fsf@soma.andreas.org> <slrn8do5of.6a0.neelk@brick.cswv.com> <WoWC4.9156$Of2.365840@typhoon.ne.mediaone.net> <38DDA6CE.2627BA57@pobox.com> <m3u2htaqau.fsf@localhost.localdomain> <38E04800.E39525DD@cup.hp.com> <Pine.GSO.3.96.1000328164553.23489F-100000@tardis.tardis.ed.ac.uk>
Reply-To: eric_gouriou@pobox.com
Xref: traf.lcs.mit.edu comp.lang.dylan:11764

 Hello,

 Thanks to Chris & Hugh for their comments.

Hugh Greene wrote:
[...]
>  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.

 Excellent news. Of course getting a nice GUI around the concept may be
a bit tricky, but if the most difficult part is already available, I
would not complain if I had to edit the .hdp file manually.

[...]
> 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.

 Oh yes, I would love to see that.
 It may also solve another Dylan shortcoming, ie that the interface
as specified in a module declaration does not document the module
intended usage properly.
 Of course we should _always_ provide complete documentation for our
libraries ( 1/2 :-) ), but having a compiler-checked interface specification
with more expressive power would be great.

[...]
> 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.

 Ok, basic agreement here.

[...]
> 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.

 I guess that the Apple Dylan team was thinking more in terms of a DB-centered
environment (as in the Dylan TR) and did not want to have the concept of
a source file embedded in the language.

>  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 think this is fine to have this mapping in the project configuration,
as in FD. However it does not solve the name collision risks, when
you really want to use an hypothetical SQL library from vendor A
ANDa an hypothetical SQL library from vendor B (to connect to 2 DBs
at the same time).

 Having  com.vendorA.SQL and  com.vendorB.SQL (as a convention)
would solve this.

> 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)?

 I do not fully understand what you are trying to solve here.
 Would this solve my hypothetical SQL libraries clashes ?

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

 As long as they appear in the not too distant future (FD 2.1, 2.2 ?),
that's fine with me. It's up to the community to define something
similar for GD if we care for it.

> >  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.

 Fine. (I like to keep as much information "in-band", but I guess .lid
files are here to stay and quite adequate).

>  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".

 HP-UX shared library versioning is explained here:
  http://docs.hp.com/hpux/pdf/B2355-90655.pdf  starting p149 

 there is also this short paper:
  http://docs.hp.com/hpux/content/v4vers.pdf

[...]
> 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
> :-)

 I can live with that (pff, that was close :-) )

 Thanks - Eric

--
Eric Gouriou                             eric_gouriou@pobox.com

Follow-Ups: