Re: ld as a functor

On Tue, Apr 25, 2017 at 2:48 PM, Florian Weimer <[email protected]> wrote:
> Sorry, this is a bit off-topic, and is perhaps a long shot.
>
> At work, something came up which made me think of a paper I might have
> read some time ago (or let's say, what I'm doing is inspired by it):
> it's about ld (the UNIX link editor/static linker) as an ML functor.
> But I can't find an online reference to it.  Does anybody know if
> something like this ever existed?
>
> The historical development may have gone in the opposite direction;
> functors as a way to do type-safe later binding, and that could have
> been based on the experiences with UNIX-style link editors.

It is certainly common to refer to ML functors as a "linking"
mechanism, especially when comparing with other kinds of grouping
mechanisms (e.g., units) or advanced features (e.g., recursive
modules).

Bob Harper and Benjamin Pierce write (in "Design Considerations for
ML-Style Module Systems" from "Advanced Topics in Types and
Programming Languages): "A variety of link-time techniques—based on
mechanisms such as “path hacking,” class loaders, and various tools
provided by the programming environment—are commonly used to achieve
effects similar to those expressible using functors. For example,
partial linking of several object files into a single,
further-linkable object file (using ld -r in Unix, for example) is
nothing but a means of defining a functor whose parameters are the
unresolved modules and whose result is the partially linked module
constructed by the linker. Because such devices are extra-linguistic
in nature, they can be unsafe because the external tools are not aware
of typing restrictions. In particular, when used for languages with
abstract types, such devices may violate coherence constraints,
leading to unsafe code. Thus, functors codify and formalize certain
extra-linguistic programming practices."

They also write: "An often-repeated argument for functors is that they
may be used as a replacement for a linking mechanism. The idea is that
all inter-module references are to be mediated by a functor—the
so-called fully functorized style of programming—so as to improve
program readability by making explicit all cross-module references.
But adopting a fully functorized style amounts to replacing each
definite reference in a module by an indefinite reference—the free
module variable is λ-abstracted in the functor. A central “linking
module” then applies these functors in dependency order to construct
the complete system; i.e., the behavior of the linker itself is
internalized and made explicit as a module-level program. Experience
has shown this to be a bad idea: all this parameterization—most of it
unnecessary—gives rise to spurious coherence issues, which must be
dealt with by explicitly (and tediously) decorating module code with
numerous sharing declarations, resulting in a net decrease in clarity
and readability for most programs."

I don't know of a paper that explicitly tries to implement ld as a
functor, or otherwise tries to explain actual object file linking in
terms of ML functors.

-- 
You received this message because you are subscribed to the Google Groups "MLton-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MLton-user mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-user