Part Twelve: Terminology

Way back when I posted Part Three on Reddit, u/moon-chilled informed me that the terminology of ‘bindings’ that I had introduced in that part was incorrect. I planned to address this in the next part, but forgot about it. Recently I remembered it for some reason, so I thought it might be a good idea to change now when very little code is affected.

Here’s u/moon-chilled’s comment in full:

A variable that you can’t vary doesn’t make much sense

Why not? The name is taken from mathematics, where it indicates something immutable and rebindable – just the same as your ‘bindings’.

The ‘vary’ comes from the fact that a variable may refer to an expression of varying or indeterminate value, like y = f(x).

A further comment down the thread from u/threewood clarified what bindings are, if they aren’t immutable variables:

Bindings keep track of a set of variable-value assignment pairs in an environment.

So if you have something like

struct Env {
    bindings: HashMap<String, Val>,
}

then that makes sense. But calling

struct Binding {
    name: String,
    expr: Expr,
}

a ‘binding’ doesn’t.

Let’s rename the only ‘binding’ reference in the entire codebase: a single test. Here’s what it looks like currently:

// expr.rs

#[cfg(test)]
mod tests {
    // snip

    #[test]
    fn parse_binding_usage() {
        check(
            "counter",
            expect![[r#"
Root@0..7
  Ident@0..7 "counter""#]],
        );
    }

    // snip
}

parse_variable_ref sounds like a good replacement to me, so we’ll update the test to be called that instead:

#[cfg(test)]
mod tests {
    // snip

    #[test]
    fn parse_variable_ref() {
        check(
            "counter",
            expect![[r#"
Root@0..7
  Ident@0..7 "counter""#]],
        );
    }

    // snip
}

I want to apologise for not doing my research before using incorrect terminology throughout the series, and for not addressing it earlier. Let me know in the comments if I should update all the previous parts to use the correct terminology, or if I should leave it the way it is to avoid confusing people who are following along.

I do realise that I promised last time that the next part would be about whitespace, but when I remembered this issue I thought it would be better to address it as soon as possible.