7 Racket, the Future: From Imperfections to Research Opportunities

Racket’s key advantage is its syntax extension system. It makes experienced programmers extremely productive, but it comes with an extraordinarily steep learning curve. Its syntax elaboration algorithm is hard to understand; its toolbox is large and complex; and it has some brittle, unexplored corners that occasionally trip up even experienced programmers. The situation calls for simplifications of the syntax system and for the creation of a smooth ramp for the toolbox (in terms of both tools and documentation).

In addition, the syntax extension system does not allow for a separation of concerns, and programs suffer from this. For example, many programming languages allow programmers to separate specifications from implementations. In conventional Racket, contracts play the role of specifications, functions implement them, and programmers may choose to separate the two concerns in a module. No such separation exists for the syntax system. While Culpepper’s dissertation (Culpepper and Felleisen 2010) research has made some progress in this direction, a lot more work on separating syntax specifications from syntax implementations is needed. Realizing both will greatly improve Racket’s support for the principle of language-oriented programming.

Besides a language, modern programmers need an ecosystem. Indeed, many programmers equate languages with their ecosystems. For Racket, this equation means that the creation of a new language ought to include the derivation of an IDE from DrRacket. To some extent, DrRacket can already support new languages automatically, e.g., with on-line syntax checking and simple refactoring actions. For other tools, such as a syntax-directed stepper, this process would need a significant amount of work and comes without guidance or automation.Spoofax (Lennart and Visser 2010) comes with domain-specific languages for the generation of IDE tools, but also relies on extra-linguistic mechanisms.

The currently available enforcement mechanisms give rise to a full spectrum of conventional programming languages: Typed Racket, Racket with contracts, Racket, and ffi/unsafe Racket. Although this spectrum is expressive, it lacks power at both ends. To achieve full control over its context, Racket probably needs access to assembly languages on all possible platforms (from hardware to the web’s JavaScript). How to integrate this power in a portable manner is unclear. To realize the full power of types, Racket will have to be equipped with dependent types. Tobin-Hochstadt and his Typed Racket group are currently working on first steps in this direction, focusing on numeric constraints in typed/racket. When a Racket program uses vectors, its corresponding typed variant type-checks what goes into these vectors and what comes out, but like ML or Haskell, indexing is left to a (contractual) check in the run-time system. Integrating Xi and Pfenning’s form of programming with numeric constraints (Xi and Pfenning 1998) into typed/racket is a natural step beyond plain types.

More generally, Racket’s spectrum of languages creates a multi-lingual world for programmers, though with far more structure than currently found in practice. Even though Matthews and Findler (Matthews and Findler 2009) have studied the basics of multi-lingual programs, their theory covers only a small part of this world. Our work on Racket clearly calls for extensions of this result in several directions, including the sound interaction between by-value and by-name (or lazy) variants of Racket, typed and dependently typed variants, and so on. We expect that studying how to protect verified code as it is co-mingled with other kinds of code will yield new insights into Racket’s safety mechanisms.

Racket must also broaden its horizon and consider security concerns, both as an enforcement action but also as an application of the third principle. While sandboxes address some of the security concerns of running a student program in a homework submission server, properly addressing this problem calls for articulating security policies and enforcing them in a system. Moore, et al. (Moore et al. 2014) recently presented Shill, a secure scripting language implemented atop Racket. Their work exposed serious gaps between Racket’s principle of language-oriented programming and its implementation as well as in Racket’s approach to enforcing security. Once again, we consider these weaknesses an opportunity to improve Racket and expect to study these problems in the near future.