Function argumnet in order

Apr 20, 2010 at 8:13 AM
Hi, I want to write a grammar for parsing function call. We have predefined function with its argument. e.g. fun#(number,string). My grammar should parse fun#(12,"test") and it should not parse fun#("test",12)
Apr 20, 2010 at 5:39 PM


I want to clarify what you are asking.  The parser aspect of Irony will parse all input you give it; the parser does not make a distinction between what it should parse and what it should not. So to clarify,  are you asking how to return an Error Token if Irony comes across a set of invalid arguments for a function?

Also, note that if you want your predefined functions to be more generic and allow nested expressions within the function's arguments, then this validation should be done by the interpreter; not by the parser/scanner.  Not taking this generic approach would mean that you would have to update your grammar every time a function is added or it's inputs are changed.


Apr 21, 2010 at 2:45 AM

Hi mindcore,

I understand parser will parse all the argument.

When we are defining Arglist for function we write




Above rule will work for functionName(Arg1,Arg2,Arg3).

Arg1, Arg2,Arg3 can be expression or number or identifier.

My problem is I want function call argument should appear in specific order.

like. It should work for functionName(expression,number), functionName(expression,identifier) but for functionName(number,expression) or functionName(identifer,expression) Isould get error token.



Apr 21, 2010 at 4:35 AM
Ashish, Function arguments should be validated after parsing because during parsing you are not going to know the primitive type of an expression or identifier. In C#, each method has an argument signature that is used to validate. This why you are able to code different methods with the same name in C#, but with varying arguments. So, this validation has to be done after parsing. It could possible be done during the AST Node creation using reflection to determine each methods parameter signature (compiled languages), or during Run-Time (DLR). There are other places that this could be done as well, it all depends on what you are trying to do. Roman may be able to give more insight as to what he has planned for Irony's interpreter. -MindCore
Apr 21, 2010 at 1:49 PM

I agree with Mindcore that the best way to do this is to verify function call nodes AFTER parsing, and not put these restrictions into the grammar


Apr 22, 2010 at 3:57 AM

Thanks to all for valuable suggestion.