Bindings - Spicery/Nutmeg GitHub Wiki

Overview

In Nutmeg, whenever a variable is introduced it is simultaneously given its first value. We call this event a binding of the variable to the value rather than and assignment. A binding cannot alter the value of a variable because (conceptually) creates the variable.

### This binds the new variable 'myshorts' to the string "eaten".
myshorts := "eaten"

In contrast to bindings, assignments (<-) change the value of variables. Nutmeg uses completely different symbols for assignment to emphasise the difference from bindings. Bindings are considered part of functional programming but assignments are not. This is because bindings cannot alter the truth of any previously true statement about the runtime but assignments can.

Modifiers: var, val, const

An introduction can be modified using one of the three mutually exclusive modifiers: var, val (default) and const. These have the following effects:

  • The var modifier allows the new variable to be the target of assignments but prevents it from being referenced in nested lambdas.
  • The val modifier prevents the new variable from being the target of assignments but allows it to be referenced in nested lambdas.
  • The const modified is like val but, in addition, the value bound is required to be const (recursively/fully immutable).

Why are var variables prevented from being referenced in nested lambdas? Many programming languages allow assignment in nested lambdas, so why doesn't Nutmeg? The answer is that Nutmeg is intended to be a teaching language, in which we teach how to blend the techniques of imperative and functional programming. We want to make the simple statement that var variables are compatible with finesses and this restriction makes that true. In addition, this restriction has an easy and instructive workaround, which is to use references.

Why is the val the default? Because in today's programming style, the majority of variables are never assigned to after their initial binding. And assigning to a variable is a big deal in terms of how you reason about a function. So we wanted to give Nutmeg coder's the reassurance that, unless otherwise stated, variables have the same value throughout their lifetime. It also allows us to write in a functional style when dealing with mutable objects. Side-effect free procedures are said to be clean.

Why are recursively immutable variables worth marking specially with the const modifier? The simple reason is that const objects are 100% safe to share and hence have a lot of efficiency benefits as well as eliminating common errors. But there is a more subtle reason too that is connected with wanting Nutmeg coders to be able to get the full advantage of functional programming style.

In pure functional programming languages such as Haskell, there is no mutable state and hence all functions have the property that when they are applied to the same arguments they return the same results. We want Nutmeg's functions to enjoy the same privilege. And we can achieve that by ensuring that their inputs must be const. (Simply being a clean procedure doesn't give the same assurance because cleanliness allows returning functions that reference mutable store.)