Daily Thought - 2024-07-01
< back to listI've been talking about binding statements versus binding expressions for a few days now. Both bind operands to names. Bindings statements do so by modifying the current scope:
# Compute a sum and bind it to the name `sum`.
a b + => sum .
# `sum` can from now on be used in this scope.
sum sum *
Binding expressions create a new scope, in which you can use the new bindings:
# Compute a sum and bind it to the name `sum`.
a b + => sum {
# This is a new scope. We can access `sum` here.
sum sum *
}
# The binding is an expression, so it returns the result of the inner scope. We
# can use that here, by chaining more operations. Or, if the function ends here,
# the result is returned to the caller.
The former represents a more imperative style, the latter a more functional one. Caterpillar will definitely be a functional language, but that doesn't mean it needs to blindly mimic everything that other functional languages do.
Whatever the solution ends up being, it needs to make sense for Caterpillar. Rust, for example, provides support for functional programming, but does pretty well with a more imperative stance on these things. I don't want to blindly mimic that either. It's another data point.