[racket] Roadmap for Racket

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Tue Jul 16 22:44:37 EDT 2013

At Sun, 14 Jul 2013 17:01:25 -0400, John Griffin wrote:
> I'm curious if there is some type of roadmap or statement of
> direction from the principals involved in Racket.

There's no formal statement, but here are some thoughts about the near

Support and Compatibility 

We love Racket, and we wish to support our users. As in the past, we
intend to improve Racket and DrRacket continuously, but we will also
preserve compatibility as much as possible.

In the case of the package system, for example, many users will
initially see no difference, because the Racket distribution will
include the same libraries, languages, and tools as it does now. In the
case of `racket2' (see below), we intend to keep `racket' modules
running in new versions of Racket.


We are currently converting Racket to a more package-oriented
organization. The package system will make it easier for users to
install new Racket libraries, languages, and tools. In addition, the
package reorganization will enable smaller Racket installations for
those users who wish to start with a minimal build (about 1/10th the
size of the current distribution) and install only the packages that
they need.

You can read more about the package system in a recent post on the
"dev" list:


(The copy of the message on lists.racket-lang.org appears to be truncated.)

The upcoming v5.3.6 will be a minor update on v5.3.5. We expect to roll
out the package-reorganized racket as v6.0 in September/October.

More Libraries, Languages, and Tools

A big motivation for the package system is to allow for new
contributions of libraries, languages, tools, DrRacket extensions, and
more. Some of those contributions will come from PLT --- along the same
lines as the `math' library, the optimization coach, the
de-modularizer, or the Marketplace language. Other contributions will
come from the larger Racket community. Either way, for those
contributions that turn out great, we expect the package system to help
us promote them. For the ones that don't turn out as well or that
become subsumed by even better contributions, we should be able to more
easily phase them out.

Racket Core Implementation

Much of the Racket run-time system is still implemented in C. We have
already started moving things out of the C core and into Racket
libraries (the GUI library is the big example), and we intend to
continue that direction. This process will take years, but it can
proceed alongside other improvements.

The most obvious pieces to move out of the core run-time system are the
macro expander and the bytecode compiler, so those pieces are first in
line, currently.

[After the package-system dust settles, my first priority is to try to
re-implement Racket's macro system. I think we can have a macro system
that is simpler and more understandable on the outside as well as the
inside. Beware, however, that this direction is a research project as
much as anything, and so I may be wrong about how it will work. Also,
as much as I want to get started, it has been difficult so far to find
the right chunk of time to get moving.]

The Next Racket

We will eventually overhaul the main Racket language.

Plans for the new language include better data structures and more
generic operations (think "good ideas from Clojure"), changing
structures to transparent and keyword-based by default, a smoother path
between structure types and classes, and more pervasive support for
in-source documentation.

The `racket' language will stay the same, so that module that starts
`#lang racket' will work as before. There will be a new language ---
`racket2', unless we think of something better --- for the new and
improved Racket. Modules written in `racket' should interoperate well
with modules written in `racket2'.

There are all sorts of issues to consider when evolving a language, and
we consider the benefits of keeping things the same as we assess our
plans for improvement. I hope the history of Racket makes clear,
however, that while we intend to keep old programs running, we also
intend to continually improve and change the language that we call

-- Matthew, in agreement with Robby, Jay, Sam, and Matthias

Posted on the users mailing list.