[Top][All Lists]

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

Re: Waddell/Dybvig module system

From: Dirk Herrmann
Subject: Re: Waddell/Dybvig module system
Date: Mon, 15 Jan 2001 15:53:56 +0100 (MET)

On 12 Jan 2001, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:
>     Dirk> To implement Dybvig's module system in an interactive
>     Dirk> environment as guile's will lead to a couple of problems: In
>     Dirk> the example above, we would like to be able to define 'y' in
>     Dirk> module M, even after M was imported somewhere.  However,
>     Dirk> after 'y' is defined in M, suddenly the semantics of the
>     Dirk> command (list x y z) changes, because now y is taken from M
>     Dirk> and no longer from the local scope.
> No.  y is not included in M's interface, so a new or redefinition of y
> in M has no effect on the binding of the identifier y in the importing
> code.

OK, replace my sloppy wording "define y" by the phrase "define and export
y" or just "export y".  The main problem stays the same:  You just don't
know any more where x, y and z are bound to just by looking at an
expression like

  (let* ((x 1) (y 2) (z 3))
    (import M)
    (list x y z))

Instead, you have to know which identifiers will be exported by M.  And,
you can only _hope_ that the next release of M will not break your code
because suddenly with the new version someone decided to export a new
identifier from M.  Sooner or later someone will get bitten because some
binding changes silently.  You can only avoid this to ever happen if you
get back to techniques like "every exported identifier in M must be
prefixed with 'M-'" or so.  Thus, as you say, a new binding or a
redefinition of some variable has no effect on the binding of identifiers
in the importing code, but changes to M's interface do very well hace such

If you import several _top-level_ environments, you can have similar
problems if suddenly two different environments start exporting the same
identifier.  In this respect, you are right that you can run into similar
problems with guile's current module system.  But, this does only
influence references to _top-level_ bindings, never to local bindings.

A consequence would be that importing from modules can only be safe if you
give an explicit list of <module identifier> pairs.  Then, changing a
module's interface can never cause bindings to get confused between
different modules.

Best regards,
Dirk Herrmann

reply via email to

[Prev in Thread] Current Thread [Next in Thread]