TITLE: Importing Language Features AUTHOR: Eugene Wallingford DATE: April 26, 2005 5:40 PM DESC: We import classes and packages that we want to use. Why can't we import language features, like call-with-current-continuation or first-class closures? ----- BODY: While doing some link surfing yesterday, I ran across an old blog entry that has a neat programming languages idea in it: Wouldn't it be nice if we could encapsulate language features. The essay considers the difference between two kinds of complexity we encounter in programs. One is complexity in the language features themselves. First-class closures or call-with-current-continuation are examples. Just having them in a language seems to complicate matters, because then we feel a need to teach people to use them. Even if we don't, some programmer may stumble across them, try to use them, and shoot himself in the foot. Such abstractions are sometimes more than the so-called ordinary programmer needs. Another kind of complexity comes from the code we write. We build a library of functions, a package of classes, or a framework. These abstractions can also be difficult to use, or it may be difficult to understand their inner workings. Yet far fewer people complain about a language having too many libraries. (*) Why? Because we can hide details in libraries, in two ways. First, in order to use Java's HashMap class, I must import java.util.HashMap explicitly. Second, once I have imported the class, I don't really need to know anything about the inner workings of the class or its package. The class exposes only a set of public methods for my use. I can write some pretty sophisticated code before I need to delve into the details of the class. Alexander asks the natural question: Why can't we encapsulate language features in a similar way? Following his example, suppose that Sun adds operator overloading to Java but doesn't want every programmer to have to deal with it. I could write a package that uses it and then add a new sort of directive at the top of my source file:
exposeFeature operatorOverloading;
Then, if other programmers wanted to use my package, they would have to import that feature into their programs:
importFeature operatorOverloading;
Such an information-hiding mechanism might make adding more powerful features to a language less onerous on everyday programmers, and thus more attractive to language designers. We might even so languages grow in different and more interesting ways. Allowing us to reveal complex language features incrementally would also change the way we teach and write about programming. I am reminded of the concept of "language levels" found in Dr. Scheme (and now in Dr. Java). But the idea of the programmer controlling the exposure of his code to individual language features seems to add a new dimension of power -- and fun -- to the mix. More grist for my Programming Languages and Compilers courses next year... ---- (*) Well, unless we want to use the language to teach introductory CS courses, of course. -----