So we have defined a set of API’s that end users (functional folks precisely) would be using to perform their data transformations. Ex, for input as Name = "XyZ", the functional folks can define a transformation rule like @Text.UpperCase(Name) to convert every value they get for name to uppercase. The way it works is that every word defined after @ is the data type and every word defined after a . is a method followed by parenthesis and a value. While this is what we have planned, I am trying to figure out if:
1> We really need a grammar that would be used to parse such inputs?
2> How can I arrange the nested calls like @Text.UpperCase(@Text.trim("XyZ "))?
You should define a grammer just to make sure you know what you will allow users to type.
You might not need a parser generator, if your grammar is simple enough (e.g., the only thing your users can type are in effect function calls over named variables). In this case, ad hoc parsing may be enough. That would be good enough for your simple example.
If your grammar has modest complexity (e.g., nested calls), you can code a recursive descent parser pretty easily that will do the job.
If you grammar gets complicated (the users will surely ask for more features), you might want a parser generator.
If it were me, with the requirements you stated, I’d build the recursive descent version, after writing a grammer that I got a parser generator to accept. That would also be useful documentation in the, ahem, user manual.