The FLANG Language

Now for the implementation — we call this new language FLANG.

First, the BNF:

And the matching type definition:

The parser for this grammar is, as usual, straightforward:

We also need to patch up the substitution function to deal with these things. The scoping rule for the new function form is, unsurprisingly, similar to the rule of with, except that there is no extra expression now, and the scoping rule for call is the same as for the arithmetic operators:

And the matching code:

---

Now, before we start working on an evaluator, we need to decide on what exactly do we use to represent values of this language. Before we had functions, we had only number values and we used Racket numbers to represent them. Now we have two kinds of values — numbers and functions. It seems easy enough to continue using Racket numbers to represent numbers, but what about functions? What should be the result of evaluating

? Well, this is the new toy we have: it should be a function value, which is something that can be used just like numbers, but instead of arithmetic operations, we can call these things. What we need is a way to avoid evaluating the body expression of the function — delay it — and instead use some value that will contain this delayed expression in a way that can be used later.

To accommodate this, we will change our implementation strategy a little: we will use our syntax objects for numbers ((Num n) instead of just n), which will be a little inconvenient when we do the arithmetic operations, but it will simplify life by making it possible to evaluate functions in a similar way: simply return their own syntax object as their values. The syntax object has what we need: the body expression that needs to be evaluated later when the function is called, and it also has the identifier name that should be replaced with the actual input to the function call. This means that evaluating:

now yields

and a number (Num 5) evaluates to (Num 5).

In a similar way, (Fun 'x (Num 2)) evaluates to (Fun 'x (Num 2)).

Why would this work? Well, because call will be very similar to with — the only difference is that its arguments are ordered a little differently, being retrieved from the function that is applied and the argument.

The formal evaluation rules are therefore treating functions like numbers, and use the syntax object to represent both values:

Note that the last rule could be written using a translation to a with expression:

And alternatively, we could specify with using call and fun:

There is a small problem in these rules which is intuitively seen by the fact that the evaluation rule for a call is expected to be very similar to the one for arithmetic operations. We now have two kinds of values, so we need to check the arithmetic operation’s arguments too:

The corresponding code is:

Note that the Call case is doing the same thing we do in the With case. In fact, we could have just generated a With expression and evaluate that instead:

The arith-op function is in charge of checking that the input values are numbers (represented as FLANG numbers), translating them to plain numbers, performing the Racket operation, then re-wrapping the result in a Num. Note how its type indicates that it is a higher-order function.

It uses the following function to convert FLANG numbers to Racket numbers. (Note that else is almost always a bad idea since it can prevent the compiler from showing you places to edit code — but this case is an exception since we never want to deal with anything other than Nums.) The reason that this function is relatively trivial is that we chose the easy way and represented numbers using Racket numbers, but we could have used strings or anything else.

We can also make things a little easier to use if we make run convert the result to a number:

Adding few simple tests we get:

---

There is still a problem with this version. First a question — if call is similar to arithmetic operations (and to with in what it actually does), then how come the code is different enough that it doesn’t even need an auxiliary function?

Second question: what should happen if we evaluate these code snippets:

Third question, what will happen if we do the above?

What we’re missing is an evaluation of the function expression, in case it’s not a literal fun form. The following fixes this:

The complete code is:

Introducing Racket’s lambda

Quick laundry list of things to go over:

• fun & lambda
• difference between lambda and simple values
• not being able to do recursive functions with let
• let* as a derived form
• let with lambda in Racket –> can be a derived form
• how if can be used to implement and and or as derived forms
• Newtonian syntax vs. a lambda expression.

Almost all modern languages have this capability. For example, this:

Can be written in JavaScript like this:

or in ES6 JavaScript:

In Perl:

In Ruby:

etc. Even Java has lambda expressions, and “recently” C++ added them too.

Using Functions as Objects

A very important aspect of Racket — using “higher order” functions — functions that get and return functions. Here is a very simple example:

Note: what we get is actually an object that remembers (by the substitution we’re doing) a number. How about:

Take this idea to the next level:

Or, with types:

Even more — why should the internal function expect a boolean and choose what to return? We can simply expect a function that will take the two values and return one:

And a typed version, using our own constructor to make it a little less painful:

Note that the Kons type definition is the same as:

so All is to polymorphic type definitions what lambda is for function definitions.

Finally, in JavaScript:

or with ES6 arrow functions, the function definitions become:

and using Typescript to add types:

Using define-type for new “type aliases”

As seen in these examples, there is another way to use define-type, using a = to create a new type name “alias” for an existing type. For example:

These uses of define-type do not define any new kind of type, they are essentially a convenience tool for making code shorter and more readable.

Note in particular that this can also be used to define “alias type constructors” too: somewhat similar to creating new “type functions”. For example:

This is something that we will only need in a few rare cases.

Currying

A curried function is a function that, instead of accepting two (or more) arguments, accepts only one and returns a function that accepts the rest. For example:

It’s easy to write functions for translating between normal and curried versions.

Typed version of that, with examples:

Usages — common with H.O. functions like map, where we want to fix one argument.

When dealing with such higher-order code, the types are very helpful, since every arrow corresponds to a function:

It is common to make the -> function type associate to the right, so you can find this type written as:

or even as

but that can be a little confusing…

Using Higher-Order & Anonymous Functions

Say that we have a function for estimating derivatives of a function at a specific point:

And say that we want to try out various functions given some plot function that draws graphs of numeric functions, for example:

The problem is that plot expects a single (Number -> Number) function — if we want to try it with a derivative, we can do this:

But this will get very tedious very fast — it is much simpler to use an anonymous function:

we can even verify that our derivative is correct by comparing a known function to its derivative

But it’s still not completely natural to do these things — you need to explicitly combine functions, which is not too convenient. Instead of doing this, we can write H.O. functions that will work with functional inputs and outputs. For example, we can write a function to subtract functions:

and the same for the derivative:

Now we can try the same in a much easier way:

More than that — our fderiv could be created from deriv automatically:

Same principle with fsub: we can write a function that converts a binary arithmetical function into a function that operates on unary numeric function. But to make things more readable we can define new types for unary and binary numeric functions:

We can do this with anything — developing a rich library of functions and functionals (functions over functions) is extremely easy… Here’s a pretty extensive yet very short library of functions:

This is written in the “untyped dialect” of the class language, but it should be easy now to add the types.

Examples:

Side-note: “Point-Free” combinators

Forming functions without using lambda (or an implicit lambda using a define syntactic sugar) is called point-free style. It’s especially popular in Haskell, where it is easier to form functions this way because of implicit currying and a large number of higher level function combinators. If used too much, it can easily lead to obfuscated code.

This is not Runtime Code Generation

All of this is similar to run-time code generation, but not really. The only thing that fderiv does is take a function and store it somewhere in the returned function, then when that function receives a number, it uses the stored function and send it to deriv with the number. We could simply write deriv as what fderiv is — which is the real derivative function:

but again, this is not faster or slower than the plain deriv. However, there are some situations where we can do some of the computation on the first-stage argument, saving work from the second stage. Here is a cooked-to-exaggeration example — we want a function that receives two inputs x, y and returns fib(x)*y, but we must use a stupid fib:

The function we want is:

If we currify it as usual (or just use currify), we get:

And try this several times:

But in the definition of bogus, notice that (fib x) does not depend on y — so we can rewrite it a little differently:

and trying the above again is much faster now:

This is therefore not doing any kind of runtime code generation, but it enables doing similar optimizations in our code. A proper RTCG facility would recompile the curried function for a given first input, and (hopefully) automatically achieve the optimization that we did in a manual way.