I stumbled across two situations where functions accept symbols as arguments, and wonder why they are designed that way. What advantages are there to using symbols? When should I write functions that accept symbols instead of strings or booleans? Here are the examples:
In the Debugger, to break on error:
Debugger.break_on(:error)
Why not write break_on to accept strings, for example, Debugger.break_on("error")?
To get the labels for the MNIST test data set:
Flux.Data.MNIST.labels(:test)
The labels can be either test or train, so why not use something like Flux.Data.MNIST.labels(test = true)?
@StefanKarpinski’s answer to “what is a Symbol?” answers this question for DataFrames, but I don’t see how the reasoning applies in the cases above. The docs on metaprogramming explain what is happening, and some of the cool things you can do with it, but not why you would want to for these use cases.
It might primarily be an aesthetic preference. I find :error to be slightly less visually noisy than "error". Text editors also often color symbols and strings different colors:
Symbols are not the same as Enums, of course, but I tend to think of them as better than strings when you want a lightweight enum, like :yes, :no, :maybe.
Symbols are similar to a global enumeration. If creating an enumeration just for that case is overkill, and the symbols are few and short, then using Symbol is often a sensible choice. Using a string would work too, but comparison of Strings is costlier, I think?
Regarding binary inputs (true/false), I don’t think that Symbols may compete with Booleans, so in that case I suppose that the reason to choose them is usability (no need to remember if true refers to train or test).
I think for most code that uses symbols or strings for mode selection, whatever difference in performance there might be between strings and symbols is negligible. For example, in this code
function foo(x; mode=:a)
if mode == :a
foo_a(x)
else
foo_b(x)
end
end
the cost of the mode == :a comparison is most likely negligible compared to the cost of running foo_a or foo_b.
Yes, you are correct (except, maybe, if the code would allocate nothing if you used symbols, and now it has to allocate strings for each comparison inside a loop or something like that).
However, often, there is no good reason to use a String in place of Symbol for such cases, and the balance ends up tipping to the Symbol side. Even if is just because experienced programmers expect it to be a Symbol.
Using expressions does put more cognitive load on new users, as it’s another bit of syntax and concept to understand. It’s also a bit intimidating, because it leads one down the path of metaprogramming.
If using a symbol only gets us a slightly cleaner style, I don’t feel it’s worth the additional complexity over a string.
According to the documentation a symbol is an “interned string”, meaning only one copy of it is stored. I think this means that when code containing a symbol is compiled, the symbol is effectively replaced by its unique id (i.e. a pointer). This makes storing, sharing, and comparing symbols efficient because they are essentially just addresses, whereas a string is a sequence of an arbitrary number of bytes.
Some comments (that are the consequences of what was already said):
Symbols are not deallocated in a single Julia session which means that they make sense if there is only a limited number of them (for ifs it is the case)
Symbol is always treated as a whole (so string operation functions do not work on Symbols - you have to convert them to string first), which sometimes is a limitation
Symbols that are not valid identifiers are relatively cumbersome to spell out (which matters in interactive use)
E.g. consideration of points 2 and 3 made us start accepting strings as column names in DataFrames.jl.
Accessing struct and NamedTuple fields is possible and fast (inlined) by symbols, which may open up optimization possibilities that are unforeseeable at API design time. Also, Dict{Symbol, Any} is faster than Dict{String, Any}, while converting a String to a Symbol is relatively slow.
As those optimization possibilities cannot always be seen at API design time, I generally find it better to use symbols for mode selection.
I have to say that for me, the profit I got from Dataframes.jl accepting strings as column names, is that I can use Symbols with the special meaning given by the macros of DataFramesMeta.jl (i.e., the column itself), but also have a simple way to refer to the column names without escaping the symbols inside the same expression.
Thanks all for the in depth responses. It sounds that using symbols versus strings may have some performance impact on the order of 10ns, which may matter for some applications. This impact comes from implementation details such as inlining, allocations, and string interning.
As a naive new user, symbols appear unusual and noteworthy, which is why I asked the original question. There are certainly plenty of examples that use strings over symbols, for example:
open("somefile.txt", "w+")
Opening a file like this is a familiar pattern across many languages, and it would be noteworthy indeed if Julia did something like:
open("somefile.txt", :w+)
The above doesn’t work, because w+ is not a symbol. It appears it’s not even possible to express w+ with an expression, because w+ is a symbol with a binary operator, which isn’t a complete expression.
Hence symbols have syntactic restrictions that strings do not, which is another disadvantage.
