At some point we switched from "internal vs external" to "implicit vs explicit" (might've been me) but it's the same basic idea. Here are some handy definitions from Owens and Flatt '06 [1]:
"Internal linking supports definite reference to a specific implementation of an interface. Internally linked module systems are common; examples include Java's packages and classes, ML's structures, and Haskell's modules. In each of these systems, two modules are linked when one directly mentions the name of another, either with a dotted path (ModuleName.x), or import statement (import ModuleName). External linking supports parameterized reference to an arbitrary implementation of an interface. ML's module system includes a functor construct that supports external linking. A functor declares an interface over which its definitions are parameterized; the parameterization is resolved outside of the functor..." In other words: in an internal linking system, each module names -- directly within its body -- the specific modules that implement its dependencies, and all the modules are wired together automatically by the linking system. In an external linking system, a module lists only its dependencies by name and/or interface, and some external linking code, written by a programmer, chooses the particular implementations of those interfaces by explicitly wiring up the module graph. Dave [1] http://www.cl.cam.ac.uk/~so294/documents/icfp06.pdf On Jun 2, 2010, at 2:08 PM, Kam Kasravi wrote: > Hi Dave > > By explicit linking are we talking about mechanism's to unambiguously > reference modules that may otherwise be ambiguous? For example in java if > 'Node' could refer to a Node class in several different packages, the > language allows one to fully qualify the Node class eg foo.Node. Just want to > make sure I'm clear on the distinction between explicit and implicit linking. > > Thx > kam > > > > On Jun 2, 2010, at 12:14 PM, David Herman <dher...@mozilla.com> wrote: > >>> I don't have the time or inclination to provide a full bibliography. >>> >>> I consider your argument withdrawn, then. >> >> Excuse me? My argument is not "withdrawn" (are we in court?). If you are >> unaware of decades of prior art on modules, that's not my failing but yours. >> >> My argument was and remains that others have gone down that road, and it's >> still very much an open research topic how to create module systems that >> provide the generality of explicit linking with the convenience of implicit >> linking. See e.g. Derek Dreyer's work, starting with his thesis and >> continuing to this day. >> >>> Possibly, depending on whether you want to present modules to themselves as >>> well. >>> >>> As I believe we discussed in our most recent f2f, it is possible to provide >>> modular code with access to its own reified module instance via some >>> distinguished symbol (e.g., "this" at the top level). And of course, >>> modular code always has direct individual access to its own exports. >> >> Hence "depending." >> >>> As recast, therefore, the example introduces Odd to "even.js" and Even to >>> "odd.js". It's pretty minimal. >> >> And yet it's still too expensive. No one will take the step from non-module >> code to module code. They just won't. Besides, a not-quite-so-bad example of >> the Odd and Even modules is pretty weak tea. >> >> The point is, you can special-case "this" if you want, but if you have a >> module graph of N modules, and each needs to be explicitly linked with N - 1 >> other modules, then you impose a quadratic code-size requirement on >> programmers. Unless, as I said, you beef up your linking-specification >> language. >> >> Dave >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
