I made a decision around the set operator in UCL this morning.

When I added the set operator, I made it such that when setting variables, you had to include the leading dollar sign:

$a = 123

The reason for this was that the set operator was also to be used for setting pseudo-variables, which had a different prefix character.

@ans = "this"

I needed the user to include the @ prefix to distinguish the two, and since one variable type required a prefix, it made sense to require it for the other.

I’ve been trying this for a while, and I’ve deceided I didn’t like it. It felt strange to me. It shouldn’t, really, as it’s similar to how variable assignments work in Go’s templating language, which I consider an inspiration for UCL. On the other hand, TCL and Bash scripts, which are also inspirations, require the variable name to be written without the leading dollar sign in assignments. Heck, UCL itself still had constructs where referencing a name for a variable is done so without a leading dollar sign, such as block inputs. And I had no interest in changing that:

proc foo { |x|
    echo $x
}

for [1 2 3] { |v| foo $v }

So I made the decision to remove the need for the dollar sign prefix in the set operator. Now, when setting a variable, only the variable name can be used:

msg = "Hello"
echo $msg

In fact, if one were to use the leading dollar sign, the program will fail with an error.

This does have some tradeoffs. The first is that I still need to use the @ prefix for setting pseudo variables, and this change will violate the likeness of how the two look in assignments:

@ans = 123
bla = 234

The second is that this breaks the likeness of how a sub-index looks when reading it, verses how it looks when it’s being modified:

a = [1 2 3]
a.(1) = 4
$a
--> [1 4 3]
$a.(1)
--> 4

(One could argue that the dollar sign prefix makes sense here as the evaluator is dereferencing the list in order to modify the specific index. That’s a good argument, but it feels a little bit too esoteric to justify the confusion it would add).

This sucks, but I think they’re tradeoffs worth making. UCL is more of a command language than a templating language, so when asked to imagine similar languages, I like to think one will respond with TCL or shell-scripts, rather than Go templates.

And honestly, I think I just prefer it this way. I feel that I’m more likely to set regular variables rather than pseudo-variables and indicies. So why not go with the approach that seems nicer if you’re likely to encounter more often.

Finally, I did try support both prefixed and non-prefixed variables in the set operator, but this just felt like I was shying away from making a decision. So it wasn’t long before I scrapped that.