Hi,
Thanks for bringing these aspects to our notice and raising the questions. Please find below my response:

1.To answer the 1st question, note that you cannot carry a statement across 2 or more lines of source code. That is, the semicolon and source statement should be placed in the same source line. Sorry, inthe problem description table we have given "var decimal" definition split across 2 lines. This happened because of word text wrapping which didn't correct. Support for CR or LF or CRLF must be provided to indicate end of line and beginning on new source statements in the next line.

2. Yes, if the characters input to the string variable is more than 256, an error "Cannot assign more than 256 characters" should be reportedin the output file and parsing stops.

3. There isn't any input length limit. Since we are doing benchmarking, we will want to have a large number of statements to exercise the parsers submitted. So, I don't have an estimate of the input size yet.

Hope this clarifies. Please let me if you want more details or have queries.

Thanks
-Rama

1.To answer the 1st question, note that you cannot carry a statement across 2 or more lines of source code. That is, the semicolon and source statement should be placed in the same source line. Sorry, inthe problem description table we have given "var decimal" definition split across 2 lines. This happened because of word text wrapping which didn't correct. Support for CR or LF or CRLF must be provided to indicate end of line and beginning on new source statements in the next line.

2. Yes, if the characters input to the string variable is more than 256, an error "Cannot assign more than 256 characters" should be reportedin the output file and parsing stops.

3. There isn't any input length limit. Since we are doing benchmarking, we will want to have a large number of statements to exercise the parsers submitted. So, I don't have an estimate of the input size yet.

Hope this clarifies. Please let me if you want more details or have queries.

Thanks
-Rama

#1: Rama, are you saying that the input files provided will not contain statements split across lines, or that CR / LF in the middle of a statement must, necessarily, be treated as an error and cause execution to stop?

Just that this adds one more error state to check for...

Hi,
From my understanding, not having multiple-line split of statements will make it easier for you to implement the parser. Otherwise, you will have to use a statement continuation symbol or assume that statements flow across multiple source lines but that has its own complexities. So, to keep it simple, a statement can span only 1 source line. However, multiple source statements can be placed on 1 source line.

Does this help answer your query?

Thanks
-Rama

Does this help answer your query?

Thanks
-Rama

I understand that one statement can occupy only one newline-terminated line. But, there can be multiple statements per newline-terminated line.

Maintaining statement continuation symbols becomes relevant if an implementation processes the input one newline-terminated line at a time. However, if I process the input file one byte at a time and simply treat space, CR, LF (, tab?) as whitespace characters, CR/LF will be ignored just like spaces. The only end-of-source-line I would need to look for is a semi-colon.

Let me re-phrase my question.

Consider the following code snippet:
averageOfValues = totalOfValues /
numberOfValues;

Again, I understand that one statement can occupy only one newline-terminated line. But, should the above statement produce an error?

In other words, will there be test cases, designed specifically to test this particular condition?

Hi Jim,
Thanks for asking questions and clarifying. To reiterate, we are looking for a parallel implementation of a simple parser and formula interpreter. So, we would like to keep the problem statement and implementation scope fairly small and exclude some of the advanced features supported in many of the modern languages.

Please find below my response to your queries. Let me know if these clarifications help.

1. Your subset of rules is a correct interpretation.

2. EOF will be determined when you reach the end of the input text file. There is no explicit EOF symbol or indicator.

3. TAB can be treated equivalent to space character. CR and LF aren't treated as space character. So, multi-line split statements are not allowed in this parser implementation. This simplifies things.

4. Operator precedence: We haven't defined one. Good point. There isn't any operator precedence. Please evaluate expressions from right to left in the RHS of the mathematical expression.

5. There is inline functions support in the parser.

6. We are not looking for IEEE support in the mathematical expressions. Output correctness is required but precision of the output will be relaxed to keep it simple.

7. Values are not stored in packed form. So, a string can have only 256 digits.

8. output(expression) where expression could result in >256 characters: It will not succeed as we have defined that the result of the expression will be converted to string and then sent to output file.

Thanks
-Rama

Hi,
I agree with your description. But we will not have test-cases that will spawn the source statements across multiple lines. If the source statements spawn multiple source lines, the parser should flag an error and stop.

Thanks
-Rama

4. Operator precedence: We haven't defined one. Good point. There isn't any operator precedence. Please evaluate expressions from right to left in the RHS of the mathematical expression.

8. output(expression) where expression could result in >256 characters: It will not succeed as we have defined that the result of the expression will be converted to string and then sent to output file.

The spec says that parentheses are used to control order evaluation, so operator precedence isn't necessary. My interpretation of that was that "a = 1 + 2 + 3" would be a syntax error, and that compound expressions would have the execution order made explicit by parenthes: "a = 1 + (2 + 3)". It is isn't a big deal to add right-to-left evaluation, so that the first example is implicitly treated as the second, but given that the present spec already deals with this (parentheses are mandatory for compound expressions) then why change it?

Hi,
I agree that we have given parentheses usage to control order of execution. But in case they aren't used, we can either flag an error or execute them to an operator precendence or execute from right-to-left or left-to-right. So, in this case, instead of flagging an error,I think it would be better to evaluate expression from right-to-left. Hope this clarifies.

Thanks
-Rama

Jim, I think you're trying to make up a different language ;-)

Jim, The kind of inline functions you mention aren't supported. The parser should support expressions as parameters, as explained in the problem description: output(25
+ 32); output(string(20)
+ string(70)); output((30
+ 20) + 10); var
str4 = "result: " + string(50 / 2); output("First
result: " + string(result)); var
powRes = pow(20 + 5, (6 / res)); output("srq:
" + string(sqrt(30)));

output("Value for a: " +
string(a));

output("Value for b: " +
string(b));

message = message + string(a / b);