7Racket, the Future: From Imperfections
to Research Opportunities

enables the rapid creation of new languages for specific problem
areas and thus enables language-oriented programming;

supports a full spectrum of general-purpose programming languages
with various conventional degrees of safety; and

internalizes mechanisms from its system context into linguistic
constructs for fine-grained, programmable control.

Turning principles into reality almost always yields an incomplete, and
possibly even flawed, product.The same caveat applies to the
design process, not only its result, but
covering the positives and negatives of the design process is beyond the
scope of this paper. Racket is no exception, but we consider these
imperfections as opportunities for future research. The remainder of this
paper sketches some of them.

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 Felleisen2010)
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 Visser2010) 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 Pfenning1998) 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 Findler2009) 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.