Level up: jsonic revisited

Throughout these tuto­rials, we’ve been relying on DrRacket as our primary tool for editing and testing code. We don’t use DrRacket because it’s manda­tory—we could use any text editor. Rather, we use it because it offers a lot of extra conve­niences: the REPL, back­ground syntax checking, indenting, syntax coloring, and toolbar buttons.

But these conve­niences aren’t just avail­able to the main Racket language and its dialects. Keeping with the spirit of Racket as a plat­form for building languages, the extra conve­niences offered by DrRacket are avail­able to any Racket-imple­mented language.

For those writing a language, this is great news. We prob­ably weren’t going to write a graph­ical IDE from scratch. But with a little extra effort, we can inte­grate our language with DrRacket.

In this section, we’ll see how this works by updating jsonic with an indenter, syntax colorer, and toolbar buttons that work in DrRacket.

The get-info func­tion

We’ve already learned that when we invoke a language—for instance, #lang jsonic—Racket starts by looking for a "main.rkt" module within the jsonic direc­tory. Within that module, it expects to find a reader submodule that provides our read-syntax func­tion. Thus our "main.rkt" for jsonic currently looks like this:

Simi­larly, when we invoke a language in DrRacket (as opposed to using racket on the command line), DrRacket looks for a get-info func­tion in the same place as read-syntax—that is, in the reader submodule of "main.rkt".

DrRacket uses the get-info func­tion to deter­mine if the language supports certain features within DrRacket, and as a way of dispatching certain tasks to func­tions we’ll provide. Without get-info, DrRacket resorts to its default settings. Thus, unlike read-syntax, get-info is always optional—a language will run fine without it.  + It’s called get-info and not get-drracket-info because tools other than DrRacket are allowed to use it too.

We’ll add our get-info directly to our reader submodule in "main.rkt":

DrRacket calls get-info with five argu­ments: an input port and four source-loca­tion fields: src-mod (the name of the module invoking get-info), plus src-line, src-col, and src-pos. DrRacket passes these argu­ments in case we want to use them to adjust how our language inte­grates with DrRacket. In this case, we don’t. So having acknowl­edged that they exist, we’ll move on.  + Curious char­ac­ters can read more about the get-info argu­ments in the Racket docs.

The result of get-info needs to be another func­tion, which we’ll call handle-query:

DrRacket will call this new func­tion with two argu­ments: a query key repre­senting a request for a certain kind of infor­ma­tion, and a default value that we should return if we don’t handle that key. The three key values we’ll handle are color-lexer (for syntax coloring), drracket:indentation, and drracket:toolbar-buttons. Inside the func­tion, we’ll branch on key using case, with a branch for each supported key, and return default in the else branch.

For each of our three supported keys, we’ll return a func­tion that handles that task for DrRacket:

These func­tions do different things, so they’ll have different kinds of input and output. We’ll cover those details in the next sections.

Here in get-info, we just have to import the modules that export those func­tions, and use them as return values of handle-query. So let’s imagine that we have three new modules in jsonic: "colorer.rkt" that provides color-jsonic, "indenter.rkt" that provides indent-jsonic, and "buttons.rkt" that provides button-list.

These func­tions are only needed when we use jsonic in DrRacket, and other­wise unnec­es­sary. There­fore, we’d like to ignore them by default, but make them avail­able to DrRacket when it requests them. To do this, we’ll use a variant of require called dynamic-require. As the name suggests, dynamic-require lets us import a func­tion from a module at run time rather than compile time. A dynamic-require expres­sion has the quoted name of the module followed by the quoted name of the func­tion:  + We quote them so they’re treated as literal names at run time. If they weren’t quoted, they’d be treated as vari­ables.

For now, since we still have to make these new modules and func­tions, let’s comment out the top three branches of the case state­ment, which we can do by prefixing each branch with #;:

As we add each of these modules in the next three sections, we’ll uncom­ment the corre­sponding branch above.