Spec's opinion on custom functions: special error messages?

[philippemerle]

Could this issue be more elaborated?

[lauwers]

The spec currently doesn't support "custom functions". Is the question whether support for "custom functions" should be added?

[philippemerle]

Custom functions can be useful, for instance to convert data from one format to another. But this could raise a new issue on how to support custom functions and portability. Perhaps introducing a new metatype could be a solution, e.g. the following snipnet

functions:
  MyFunction:
    description: This is my custom function
    inputs:
      p1:
        type: integer
   result:
      type: string
   implementation: MyFunction.py

defines a custom function taking an integer parameter, returning a string and implemented by the MyFunction.py script. inputsand implementationare already defined in the TOSCA language. resultis like a parameter definition. So the effort to support functions into a parser could be limited.

[tliron]

I think it's hard or even impossible to declare signatures. For example, even something like get_property has dynamic argument types that depend on the path (sometimes they are strings, sometimes they are integers i.e. for list indexes). Even the return type is highly dynamic: get_property's return type depends on the value you are getting. But this does raise the bigger question as to how to validate return types for functions. It ends up being particular to the function.

What I suggested is that we use a prefix (something like &) for function calls. What happens to an unknown function depends on the implementation. They can emit a warning, fail, or just not do anything if that function call never happens.

[tliron]

See also #70

[philippemerle]

I agree that a signature declarative approach should not be appropriated for declaring functions like get_property and get_attribute. But these functions are already built-in functions. We should collect concrete use cases for custom functions in order to identify requirements. Perhaps other functions similar to get_property will be required, perhaps only functions with a static typed signature will be required.

[tliron]

It's not hard to come up with use cases for functions similar to get_property in that they accept dynamic arguments and return dynamic values.

Generally speaking function signatures are a rather weak validation. All they can do is check the types, but they can't check values and the relationship between values, which is unique to each function's semantics. Importantly, these semantics can depend on the runtime environment, so Day 0 tools wouldn't be able to do much with them anyway. I believe these would be the main use for custom functions: allowing users to interact with (usually to extract data from) their special dev, deployment, and runtime environment.

Languages like Haskell do have contracts that go way beyond signatures, but I see no value in TOSCA pursuing such strict validation.

In my opinion TOSCA functions should be more like functions in dynamic languages: Python, Ruby, JavaScript, etc.. They have a name, they accept one or more arguments, and return one value (which could be of a complex data type). This is a paradigm that is familiar to everyone.

If we absolutely want functions to be declared (I'm not sure we have to) then I suggest nothing more then declaring their name.

[lauwers]

At a minimum, TOSCA parsers should check whether the type of the return value of the function is compatible with the type of the parameter to which the function value is assigned.

From: Tal Liron @.> Sent: Sunday, March 13, 2022 10:14 PM To: oasis-open/tosca-community-contributions @.> Cc: Chris Lauwers @.>; Comment @.> Subject: Re: [oasis-open/tosca-community-contributions] Spec's opinion on custom functions: special error messages? (Issue #68)

It's not hard to come up with use cases for functions similar to get_property in that they accept dynamic arguments and return dynamic values.

Generally speaking function signatures are a rather weak validation. All they can do is check the types, but they can't check values and the relationship between values, which is unique to each function's semantics. Importantly, these semantics can depend on the runtime environment, so Day 0 tools wouldn't be able to do much with them anyway. I believe these would be the main use for custom functions: allowing users to interact with (usually to extract data from) their special dev, deployment, and runtime environment.

Languages like Haskell do have contracts that go way beyond signatures, but I see no value in TOSCA pursuing such strict validation.

In my opinion TOSCA functions should be more like functions in dynamic languages: Python, Ruby, JavaScript, etc.. They have a name, they accept one or more arguments, and return one value (which could be of a complex data type). This is a paradigm that is familiar to everyone.

If we absolutely want functions to be declared (I'm not sure we have to) then I suggest nothing more then declaring their name.

— Reply to this email directly, view it on GitHubhttps://github.com/oasis-open/tosca-community-contributions/issues/68#issuecomment-1066357125, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AASPLIIOI477LAYE3JM35VTU73KIVANCNFSM5QNLLTBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.**@.>>

[lauwers]

Custom functions (and associated signatures) are now supported and documented in https://docs.oasis-open.org/tosca/TOSCA/v2.0/csd05/TOSCA-v2.0-csd05.html#_Toc125468802.