Improve delimited identifier syntax

[hasithaa]

With #656, we are using Option I described https://github.com/ballerina-platform/ballerina-spec/issues/243#issuecomment-505286455;

We have noticed an increased usage of this syntax in URLs for services, particularly those that include underscores, such as foo\-bar\-baz. One piece of feedback from users indicates that readability is compromised when more special characters are present in the identifier due to the escape characters.

A viable solution could be improving the quoted identifier syntax for this purpose. For example, by using 'foo-bar-baz'.

@jclark @sameerajayasoma @shafreenAnfar thoughts?

[jclark]

Is the user problem specifically in resource paths?

Changing syntax for identifiers generally is going to be very constrained by compatibility issues. There's more scope for a more flexible syntax specifically in resource paths (in resource method definitions and resource-access-action), because they are occur in contexts where arbitrary expressions are not allowed. The cost would be another lexical mode.

[hasithaa]

Is the user problem specifically in resource paths?

Yes,

[jclark]

It would be difficult to extend the syntax in the client-resource-access-action, because that occurs nested within other constructs and isn't always followed by an opening parenthesis, so a resource-method-name can be followed by an operator.

But within a resource-method-definition, there is more flexibility.

The relevant URL syntax is:

psegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
uchar          = unreserved | escape
unreserved     = alpha | digit | safe | extra
safe           = "$" | "-" | "_" | "." | "+"
extra          = "!" | "*" | "'" | "(" | ")" | ","

which gives these characters not allowed in identifiers but allowed in URL path segments ?:@&=$-.+!*'"(),

I see two characters there that won't work:

• ( because it starts the function signature;
• ' because it has a meaning of starting a delimited identifier.

Another possibility would be to support a completely different syntax approach to resource-path based on backticks. This might tie into #1238.

[jclark]

Another possibility is to allow the user to provide the HTTP listener with a split function that the HTTP listener will call to split the URL into segments, instead of/in addition to splitting the URL into segments as defined by the URL spec.