It seems strange to me that
using Test
@test Symbol("true") != :true
Since
@test Symbol("foo") == :foo
@test Symbol("bar") == :bar
@test Symbol("baz") == :baz
# ...
Suppose we have a function that generate a symbol from a string.
How can we be sure that output will match independently of some special input provided ?
Err… that function is called “Symbol”, assuming the string is valid of course
julia> Symbol("\0a")
ERROR: ArgumentError: Symbol name may not contain \0
Stacktrace:
[1] Symbol(::String) at ./boot.jl:433
[2] top-level scope at none:0
so it’s not very clear what you meant by
The question in the title is simply because :<...> isn’t the syntax to create symbol, even though it might be confusingly closed to be that. The syntax is for quoting and the quoting of the literal true is simply still true, just like any number literals. Also see Added `sym"..."` string macro for making `Symbol`s by andyferris · Pull Request #32707 · JuliaLang/julia · GitHub, which is not necessarily the way forward (I’m neutral on it for the record) but give you links to other related discussions that you can read about.
If you have any other question about practical usage of the quote syntax or the Symbol functions, please clarify…
Oh wow, I had always assumed that :<...> was actually syntax to create a symbol, and the docs certainly suggest that right now. I had always assumed that to create something other than a Symbol (for example an Expr) one would need to use parenthesis, i.e. I had assumed that :(<...>) was used for that.
I have to admit that the current behavior seems a landmine to me, in particular given how widespread the use of the :<...> syntax is to create symbols… I think I would much prefer if the actual behavior was what I had assumed it was.
Nop
julia> :[1, 2, 3]
:([1, 2, 3])
Yes, I see the point. I have little preference on that ATM but I do want to say that we do need a syntax for quoting (it could be :() of course) and I think we didn’t have a dedicated symbol syntax simply because the current one is good enough in most cases…
You are right
@test :true isa Bool
a kind of operator precedence issue between quoting and symbol creation.
You oversimplify the generation things. One can generate symbol as black box id (may be with a seed).
That could be an issue if one map symbol to id and assume that reserving them identifier names is enough to allow correct input. At some point, true and false have to be discarded as identifier too.
Not it’s not due to operator precedence at all. There’s no symbol creation operator. There’s only a quoting operator.
I don’t know what did I simplify about which generation things. The only “generate”/“generation” I could find above is about “generate a symbol from a string”. You seems to be mentioning some usecases following that so you should clearify your usecase if you want to get help on that. Otherwise, I’m afraid I don’t really know what I’m “oversimplifying”. As far as creating/generating a symbol from a string is concerned, Symbol should be all what you need. If you have a particular use of the Symbol in mind afterwards that puts other constraints on what symbol you can use, then you certainly need to take that into account.
Thanks for your quick answer Yichao
If symbol are only created and handled in julia, yours observations are corrects.
If we consider Symbol in Julia ≅ ID in Db and bring them back in julia to algebraically manipulate them, one could have to consider special corners cases at the boundary. (May be a reason why Mr QueryVerse react so promptly too 
On a related note, I believe true, false, ccall and cglobal are four symbols that aren’t allowed to be variable names, in case that’s the usage you have in mind… Though really, for code generation you should probably use something that allow you to not worry about any of these…
I’m afraid I have no idea what’s “ID in Db” and what’s “algebraically manipulate them”. If you are talking about crossing some language bundary then there will certainly be limitations there that you need to consider, largely unrelated to julia.
The limitation posed by julia syntax will only affect you when you want to use them in julia code. It’s fine even if you are using julia expressions but don’t run them as julia code. In another word, you can play with :($(Symbol("true")) * 2) all day long and julia won’t care even a little bit about it as long as you don’t try to evaluate it as julia code.
Buttom line is, if you are going to use it, of course you’ll hit application dependent limitation. Very few language I know doesn’t have special syntax/keyword anyway. I can’t say for the limitation if you are using it as something else but if you are going to use it in anyway that will make you hit the limitation posed by julia syntax, you are going to be evaluating the symbol you created as julia code. Doing that is by all mean code generation and there are many ways you could (and should) use so that you won’t ever hit this and many other related issues.