Clone wiki

templ / programming_notes

Misc Notes

Note that there are no mutable values in templ. Strings, Lists, and...well that's actually about it, are all immutable. Operations on them, like slice, splice, append, substr, etc., all just create new objects.

Design Decisions

Or: Why I did some of the things I did


I only let void accept at most one expression because otherwise I have to deal with Returns and stuff. I already have that in {:} and {::}.

Vota ($$)

Why not use {$$} for something like a double lookup, like {$$ X} = {$ {$ X}}. Because how often does that really come up? This seemed pretty reasonable.


I avoided overloading almost entirely, and request/prefer that any added built-in executables or even user executables, do so as well. In other words, a function should not, in general, operate differently deending on the type of arguments. For instance, you wouldn't use the same function to concatenate strings and lists, let alone add two numbers.

The reason is to avoid confusion. Specifically, the case where a programmer looses track of the value at a particular symbol, and so they accidentally pass the wrong type into a function. What we want to avoid is the case where there is no failure, per se, as a result, but the function does something they weren't expecting because the type wasn't what they thought.

The few exceptions are executables that sort of explicitely do different things for different types: things like getset, equals, str, etc. In those cases, the whole point is to do something regardless of the type of the arg.


Executables that implicitely create new variables should only create variables in the local scope and should prefix them with ":", like the ":args" variable when userfuncs are executed. If a user provides names for them, then it is generally considered explicit and you can (probably should) use the names they give you, don't need to prefix with ":" or anything. When users are giving such names, they should not use the ":" prefix.

built-in executables

For argument count checking, it is preferred to use the `exact` parameter if there are no more than 4 possible argument counts allowed. If you have more than that, `min` and `max` preferred when it makes sense.

It is preferred to check the number of arguments first, and raise that error before anything else. Then, it is preferred to do all up-front checking on arguments one at a time in order given (low index to high index). In other words, we don't want to see any error for argument 2, fix that, and then find out there's an error with argument 1. It's annoying.