State and Environments

A quick example of how mutation can be used:

and compare that to:

It is a good idea if you follow the exact evaluation of

and see how both bindings have separate environment so each one gets its own private state. The equivalent code in the homework interpreter extended with set! doesn’t need boxes:

To see multiple values from a single expression you can extend the language with a list binding. As a temporary hack, we can use dummy function inputs to cover for our lack of nullary functions, and use with (with dummy bound ids) to sequence multiple expressions:

Note that we cannot describe this behavior with substitution rules! We now use the environments to make it possible to change bindings — so finally an environment is actually an environment rather than a substitution cache.

When you look at the above, note that we still use lexical scope — in fact, the local binding is actually a private state that nobody can access. For example, if we write this:

then the resulting function that us bound to counter keeps a local integer state which no other code can access — you cannot modify it, reset it, or even know if it is really an integer that is used in there.

Implementing Objects with State

We have already seen how several pieces of information can be encapsulate in a Racket closure that keeps them all; now we can do a little more — we can actually have mutable state, which leads to a natural way to implement objects. For example:

implements a constructor for point objects which keep two values and can move one of them. Note that the messages act as a form of methods, and that the values themselves are hidden and are accessible only through the interface that these messages make. For example, if these points correspond to some graphic object on the screen, we can easily incorporate a necessary screen update:

and be sure that this is always done when the value changes — since there is no way to change the value except through this interface.

A more complete example would define functions that actually send these messages — here is a better implementation of a point object and the corresponding accessors and mutators:

And a quick imitation of inheritance can be achieved using delegation to an instance of the super-class:

You can see how all of these could come from some preprocessing of a more normal-looking class definition form, like:

The Toy Language

Not in PLAI

A quick note: from now on, we will work with a variation of our language — it will change the syntax to look a little more like Racket, and we will use Racket values for values in our language and Racket functions for built-ins in our language.

Main highlights:

• There can be multiple bindings in function arguments and local bind forms — the names are required to be distinct.

• There are now a few keywords like bind that are parsed in a special way. Other forms are taken as function application, which means that there are no special parse rules (and AST entries) for arithmetic functions. They’re now bindings in the global environment, and treated in the same way as all bindings. For example, * is an expression that evaluates to the primitive multiplication function, and {bind {{+ *}} {+ 2 3}} evaluates to 6.

• Since function applications are now the same for primitive functions and user-bound functions, there is no need for a call keyword. Note that the function call part of the parser must be last, since it should apply only if the input is not some other known form.

• Note the use of make-untyped-list-function: it’s a library function (included in the course language) that can convert a few known Racket functions to a function that consumes a list of any Racket values, and returns the result of applying the given Racket function on these values. For example:

  (define add (make-untyped-list-function +))
  (add (list 1 2 3 4))

  evaluates to 10.

• Another important aspect of this is its type — the type of add in the previous example is (List -> Any), so the resulting function can consume any input values. If it gets a bad value, it will throw an appropriate error. This is a hack: it basically means that the resulting add function has a very generic type (requiring just a list), so errors can be thrown at run-time. However, in this case, a better solution is not going to make these run-time errors go away because the language that we’re implementing is not statically typed.

• The benefit of this is that we can avoid the hassle of more verbose code by letting these functions dynamically check the input values, so we can use a single RktV variant in VAL which wraps any Racket value. (Otherwise we’d need different wrappers for different types, and implement these dynamic checks.)

The following is the complete implementation.