OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca] New syntax for function calls


Good point, there isn't any ambiguity if there's a leading escape character. I was thing more about your example for node templates, e.g.Â
"{ concat: [ site-, { get_variable: [ SITE, name ] } ] }"

How do you know it'sÂnot a template with that name?

BTW, for the issue you brought up about functions, in Unfurl I have a function called "q" (for "quote") that resolves to its value. That solves the problem in a similarÂway but doesn't introduce any new syntax.

Adam


á

On Tue, Mar 16, 2021 at 4:50 PM Tal Liron <tliron@redhat.com> wrote:
Ah, you're right -- it's actually the double !! that would be a problem. We can choose a different character, like "@" or "%".

I don't think this is a problem for "any string", as you say. Function calls can only exist within value assignments of properties, attributes, and parameters, and they must also be a YAML map with a single string key.

On Tue, Mar 16, 2021 at 3:01 PM adam souzis <adam@souzis.com> wrote:
This is interesting idea but leading "!" is reserved in yaml for tags (seeÂhttps://camel.readthedocs.io/en/latest/yamlref.html#tags) and so these would always need to be quoted with is awkward.

Also, I should note that since we currently accept any string with no constraints as a valid identifier any kind of syntax like this (or a syntax for generating template names like you previously proposed) are ambiguous.Â

-- Adam

á

On Tue, Mar 16, 2021 at 10:56 AM Tal Liron <tliron@redhat.com> wrote:
This is an old topic, but worth resurrecting.

The problem with the current syntax:

mynode:
 type: MyType
 properties:
  name: { get_input: site }

Is that locks away the function name from being used as a map key. What do I mean? Let's rewrite it with a different notation, just to emphasize that it is indeed a map:

mynode:
 type: MyType
 properties:
ÂÂÂ name:
ÂÂÂÂÂ get_input: site

Now imagine this definition:

MyType:
 properties:
ÂÂÂ name:
ÂÂÂÂÂ type: map

As you can see, the parser has no trivial way to distinguish "get_input" from being a function call vs. being a literal key in a map with a single key.

There's another more subtle problem. if someone tries to call a non-existent function, they would get a confusing error, e.g.:

mynode:
 type: MyType
 properties:
  name: { get_output: site }

There's currently no "get_output" function in TOSCA. But, the error would not be about a non-existing function, it would be about trying to assign a map to something that is not a map. Things could get even worse if the property type actually is a map! The service template will be silently processed, and the user would not even know that the supposed function was not processed! It could lead to very hard-to-find bugs.

I propose adding a prefix character to all function calls. I'll arbitrarily choose "!". E.g.:

mynode:
 type: MyType
 properties:
ÂÂÂ name: { !get_input: site }

All these problems now disappear. When encountering a "!" prefix for a map with a single key, the TOSCA parser will expect it to be a function call and will emit a clear error if the function name is not recognized.

You might be asking how to handle a literal map with a single key that really has a "!" prefix. Well, we can support escaping using a double prefix, e.g.

mynode:
 type: MyType
 properties:
ÂÂÂ name:
ÂÂÂÂÂ !!not-a-function: site

The double "!!" will become a single "!" and it will not be treated as a function call. This is deterministic and, as long as it's documented, should not be confusing, especially since it would likely be a very rare use case.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]