There’s no way around eval if you want to handle arbitrary types. Many people seems to think macro gives you magic power to accomplish things (edit: at runtime) that are not possible without them. They don’t, they are just a fancy way to save repeated typing.
Going from string to value is not parsing, its evaluating (ok, parsing (to AST) plus evaluating (to value)). The only way to evaluate something from a runtime expression is eval, everything else is just eval wrapped in one way or another, including include, include_string etc.
The real question is what property you want. Do you want to handle all possible types? If yes, then you have to use eval. Do you want to avoid code injection attach? Then you can’t use eval, you can use a table (Dict) or use an arbitrary set of operations you support and are safe for your application.
They are not. Not for the parser and not any more than basically anything else. Types are values, they are special in dispatch but that has nothing to do with syntax/parsing. Designing a system that give them more coupling is possible (C++…) but that’s usually not a desired property and makes parsing so much harder.
As an example, what do you think the last B in the following code should parse to?
a = 2 + 2
struct B
x::NTuple{a,Int}
end
B
It’s obviously a type (which is clear in this case but does not have to in general in julia) but how do you want the parser to figure out all it’s property before the code is evaluated?