As a corollary to my proposal for a prefix character for function names, I would add that we would need a prefix character for our "magic names", too, and for many of the same reasons. Here's a simple example that shows the problem:
topology_template:
 node_templates:
  SELF:
ÂÂÂÂÂ type: ServerPool
ÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂ name: mypool
ÂÂÂ IMPLEMENTATION:
ÂÂÂÂÂ type: Server
ÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂ name: nyname
ÂÂÂÂÂÂÂ additional_name: { @get_property [ SELF, name ] } # here we mean ourselves
ÂÂÂÂÂÂÂ pool_name: { @get_property [ SELF, name ] } # here we mean the node template named 'SELF'
The above is obviously broken in TOSCA. Basically all the magic keywords cannot be used as template names. This doesn't sound like a big deal, but certain edge cases can be problematic, e.g. a TOSCA code generator. Let's fix this by using a prefix (which is again escapable by doubling):
topology_template:
 node_templates:
  SELF:
ÂÂÂÂÂ type: ServerPool
ÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂ name: mypool
ÂÂÂ IMPLEMENTATION:
ÂÂÂÂÂ type: Server
ÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂ name: nyname
ÂÂÂÂÂÂÂ additional_name: { @get_property [ @self, name ] } # no ambiguity, magic name is prefixed
ÂÂÂÂÂÂÂ pool_name: { @get_property [ SELF, name ] } # no ambiguity, it's a template name
The escaping rule is very clear (use "@@" for anything that needs to begin with "@") and is deterministically possible to algortihmize into things like TOSCA generators without them having to be hardcoded with a list of forbidden magic names.
Another aspect to this -- if we want to talk about allowing TOSCA to be extended by adding custom functions, it's very useful in the same context to talk about extending via custom magic names. From an implementation perspective they really are the same, there's just a simpler syntax allowed here for a zero argument function call. E.g. you can think of the "@self" magic name as syntactically equivalent to this:
 value: { @self: [] }
I think it's worth allowing this if we already want to allow custom functions, as it can lead to cleaner syntax. For example, there would be a way here to recreate the Simple Profile's "HOST" magic name. This is a feature we removed from TOSCA 2.0 for good reasons -- it's extremely implementation-specific. Well, then, specific implementations of TOSCA could allow for such useful features by such grammatical extensions.
