Closing the loop: basic

Func­tions in BASIC are intro­duced with the def state­ment, and can be invoked with any expres­sions (including other func­tion appli­ca­tions) as argu­ments. The result of the func­tion is a single expres­sion:

Pedaling uphill

We prob­ably noticed that def is similar to let in that it assigns a value to an iden­ti­fier. So we can already guess that we’ll imple­ment def by making the usual lexer and parser updates, and then in the expander, converting it into a lambda expres­sion that gets assigned to the func­tion iden­ti­fier. Right. Hope­fully, at this point, that much seems easy.

The harder part is the last require­ment: that every func­tion defined in the program, no matter where, can be invoked right away. This means that our def state­ments have to circum­vent the usual control flow. They have to be moved out of our list of line func­tions to the top of the module, so they get eval­u­ated right away.

In a sense, it’s similar to the situ­a­tion we confronted in the previous tuto­rial when imple­menting vari­ables. In that case, we found the unique vari­able names throughout the program by flat­tening the parse tree and looking for items with the 'b-id syntax prop­erty.

But that was possible because an iden­ti­fier is a stand­alone item, so we could afford to discard the struc­ture of the parse tree in our search. In this case, we need to keep each of the b-def nodes intact.

If we wanted, we could pick through the parse tree a little more gingerly and hoist the b-def nodes to the top level. But this is a common enough task that Racket’s macro system has beaten us to it: as we’ll see, we can simply tell Racket to move the result of a macro to the top level of our module by using a lift. Best of all, using the lift is a lot easier than explaining why we need it.

Lexer updates

To our lexer, we add def and , to our list of reserved-terms (we need the comma for sepa­rating the argu­ments in a func­tion call):

Parser updates

In our parser, we create new rules to handle the def state­ment itself, but also to support func­tion calls as expres­sions:

The b-def rule follows the style we saw above:

Where we have a func­tion name, a list of comma-sepa­rated vari­ables between paren­theses, and finally an expres­sion:

Then we also want to be able to parse func­tion calls. Near the bottom, we add a b-func rule as a possible b-value. The b-func rule follows pattern similar to b-def, with a func­tion iden­ti­fier followed by comma-sepa­rated argu­ments between paren­theses:

There’s a subtle maneuver here. Rather than matching the b-id rule in the first posi­tion, we’re delib­er­ately matching a raw ID token.

Why? We recall from our imple­men­ta­tion of vari­ables that every­thing marked as a b-id in the parse tree will be hoisted into the top level of our module and defined as a new vari­able with value 0. Usually that’s what we want, so that a program refer­ring to an unde­clared vari­able will just print 0:

But what should happen when an unde­clared vari­able is called as a func­tion?

If we use b-id in the pattern for b-func, we’d be signaling that the unde­clared f should be initial­ized to 0. That means our f(42) would become 0(42). Which is mean­ing­less.

There­fore, we’d rather trigger a stan­dard unbound-iden­ti­fier error. We do this by using ID rather than b-id, which will match the right kind of token, but won’t cause the vari­able to be auto­mat­i­cally defined. That way, when we try to call an unde­fined func­tion, we get this instead:

In so doing, we’re choosing to handle this condi­tion as a compile-time error. It wouldn’t be wrong to just let the expres­sion become 0(42) and then raise a run-time error. For instance, our b-func macro that will be handling func­tion calls could notice the 0 in the func­tion posi­tion and call raise-line-error.

But there are two argu­ments for doing it this way. First, it’s polite to raise an error as soon it can be noticed, rather than procras­ti­nate. Here, the error can be detected at compile time, so we should raise it at compile time. More­over, if we defer it into run time, it may take a long time to cause a problem. Second, we can make the behavior of basic in this situ­a­tion consis­tent with regular Racket, with the familiar “unbound iden­ti­fier” error.

Expander updates

Now we need to add two macros to our "expr.rkt" module to handle our new b-def and b-func nodes in the parse tree. At the top, we import "line.rkt" so we can use our raise-line-error func­tion below. We also export our two new b-def and b-func macros:

Our b-def macro rewrites the func­tion defi­n­i­tion as a lambda expres­sion, and then uses set! to assign it to FUNC-ID.

To get this expres­sion to the top of our module, we wrap the macro result in syntax-local-lift-expression, which is like a magic compile-time elevator that moves a syntax object to the top of its enclosing module.

Since macros are a big part of how Racket works, it includes a set of syntax-trans­for­ma­tion tools—not usually needed, and some arcane—that simplify certain oper­a­tions within macros. syntax-local-lift-expression has an imposing name, but this simpli­fied example illus­trates what it does:

Ordi­narily, we’d expect 'whee to be displayed after 'let-start and before 'let-end. But the lift moves (displayln 'whee)) to the top level of the module, just before its enclosing let, so the code is rearranged like so:

When we run the orig­inal sample, the expres­sions are displayed in this lift-adjusted order:

Racket won’t have a special­ized syntax-trans­for­ma­tion tool for every task. But in those cases, we can usually get the job done by manip­u­lating the parse tree by hand (as we did with vari­ables). Here, we lucked out, because the lift does exactly what we want.

The b-func macro is pretty easy: all we need to do is apply FUNC-ID to its list of ARGs. To be safe, we add a check to make sure that FUNC-ID is a procedure?. It will be if there was a corre­sponding def state­ment that assigned a lambda to that vari­able. But it’s also possible for the vari­able to be assigned an inap­pro­priate value.

In that case, we use raise-line-error to stop the program with an infor­ma­tive message. Note how we’re using the pattern vari­able FUNC-ID twice in the error message:

The quoted form repre­sents its literal name at compile time; the unquoted form will repre­sent its value at run time.

Testing our func­tions

We should now be able to run our orig­inal test program:

Let’s also see what happens when we hide one of our func­tion defi­n­i­tions with rem:

And let’s see what happens when we define a func­tion correctly but then reas­sign it a bad value: