Re: New syntax for function calls

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.

tosca message