Attempt at formal syntax

Attempt at formal syntax

Bild des Benutzers john_e_lilley

To help us all solve the same problem, I'm submitting this as a syntax. I mix lexical and syntactic, and imply that whitespace is ignored between tokens. I also assume */ is higher than +-. Please comment. john
Program := SourceLine* SourceLine := Statement* (Newline | Eof) Statement := (Variable | Free | Assignment | Output) ';' Newline := '\\r'? '\\n' Eof := Variable := "var" Identifier ('=' Expression)? Free := "free" '(' Identifier ')' Assignment := Identifier '=' Expression Output := "output" '(' Expression ')' Identifier := [a-zA-Z][A-Za-z0-9]* Expression := AddExpr AddExpr := MultExpr (AddOp MultExpr)* MultExpr := UnaryExpr (MultOp UnaryExpr)* UnaryExpr := StringExpr | '-'? (ParenExpr | Constant) StringExpr := "string" ParenExpr ParenExpr := '(' AddExpr ')' Constant := StringConstant | NumericConstant StringConstant = '"' [a-zA-Z0-9 ]* '"' NumericConstant = [0-9]* '.' [0-9]+ | [0-9]+ ('.' [0-9]*)?

11 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers john_e_lilley
After realizing that () cannot exist in string expressions, its easy to move the differentiation of string and numeric expessions from semantic to syntactic. I also forgot the functions and operators :-) Program := SourceLine* SourceLine := Statement* (Newline | Eof) Statement := (Variable | Free | Assignment | Output) ';' Newline := '\r'? '\n' Eof := Variable := "var" Identifier ('=' Expression)? Free := "free" '(' Identifier ')' Assignment := Identifier '=' Expression Output := "output" '(' Expression ')' Identifier := [a-zA-Z][A-Za-z0-9]* Expression := AddExpr | StringExpr AddExpr := MultExpr (AddOp MultExpr)* AddOp := [+-] MultExpr := UnaryExpr (MultOp UnaryExpr)* MultOp := [/*] UnaryExpr := '-'? (ParenExpr | FunctionExpr | NumericConstant) ParenExpr := '(' AddExpr ')' FunctionExpr := ("pow" | "sqrt") '(' AddExpr ')' NumericConstant = [0-9]* '.' [0-9]+ | [0-9]+ ('.' [0-9]*)? StringExpr := StringAtomicExpr ('+' StringAtomicExpr)* StringAtomicExpr := "string" ParenExpr | StringConstant StringConstant = '"' [a-zA-Z0-9 ]* '"'
Bild des Benutzers Minh-Nhut Hong

Thanks John for posting this. It is what I am asking for in other thread. We are supposed to focus on multithreaded implemetation of parser/interpreter, not the syntax of language. This is good.

Bild des Benutzers john_e_lilley

Ah yes I didn't see your post:http://software.intel.com/en-us/forums/showthread.php?t=83283&o=a&s=lr I think our syntax are equivalent, except that you have all operators at equal precedence and I have */ higher. Can we get resolution on this matter from judges please? Perhaps the precedence issue was already resolved and I just haven't seen it yet. Also it seems there was some question about whether assignment without "var" can be done, but it looks like Rama's answer is "yes it can".

Bild des Benutzers john_e_lilley

One other ambiguity is whether variables can be keywords, e.g.: var var = 1; var string = 3; or function names: var sqrt = 4; I hope the answer is "no".

Bild des Benutzers mdma

Since the spec says that parentheses are used to explicitly control the evaluation order, I've given all operators equal precedence, Expr := Term ['+' | '-' | '/' | '*'] Term Term := numericLiteral | '(' Expr ')' This makes "1 + 2 +3" illegal, but "1 + (2 + 3)" not.

Bild des Benutzers DweeberlyLoom
Quoting john_e_lilley After realizing that () cannot exist in string expressions, its easy to move the differentiation of string and numeric expessions from semantic to syntactic. I also forgot the functions and operators :-) Program := SourceLine* SourceLine := Statement* (Newline | Eof) Statement := (Variable | Free | Assignment | Output) ';' ... StringExpr := StringAtomicExpr ('+' StringAtomicExpr)* StringAtomicExpr := "string" ParenExpr | StringConstant StringConstant = '"' [a-zA-Z0-9 ]* '"'

From another thread I believe that only one statement per line is allowed, so I think 'SourceLine' should be

SourceLine := Statement (newline|eof)

I also remember reading something that seemed to say that '\r', '\n' or '\r\n' were valid line terminators, but I dislike a single '\r' line terminator so much I'm going to assume it's wrong.

Might want some grouping on the 'StringAtomicExpr' to show that "string" is only associated with ParenExpr. Using ParenExpr -> AddOp implies "abc" - "xyz" is a valid statement.

I think you can get away with this for NumericConstant (depending on if a zero is required before the decimal point or not):

NumericConstant = ([0-9]*'.')?[0-9]+

It might be better to define the expessions seperately for string and numeric, this is more verbose but clearer:

NumGroupExpr := '(' NumExpr ')'

NumExpr := NumToken (NumOp NumToken)*

NumOp := [+-/*]

NumToken := UnaryExpr (NumConstant | Identifier | NumExpr | NumGroupExpr)

UnaryExpr := [+-]*

FunctionExpr := ("pow" | "sqrt") '(' NumToken ')'

StringGroupExpr := '(' StringExpr ')'

StringExpr := StringToken ('+' StringToken)*

StringToken := StringConstant | Identifier | StringExpr | StringGroupExpr

StringConstant = '"' [a-zA-Z0-9 ]{0,256} '"'

StringFunc := 'string(' StringToken ')'

Expression := NumExpr | StringExpr

Bild des Benutzers mdma

Multiple statements per line is valid. (But not multiple lines per statement.)

var a = 1; var b = 2; var c = 3;
is valid seehttp://software.intel.com/en-us/forums/showpost.php?p=152260
Bild des Benutzers DweeberlyLoom

Thanks I had missed that. For the recordInput clarificationstates:

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

There are some other interesting syntax related bits there too:

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.

Tab had not previously been mentioned ... I assume this also applies to string constants.

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.

Ok, this isn't really a syntax thing but it is different from what most of us are use to.

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.

This implies the above definition of StringFunc or StringAtomicExpr will have to be corrected.

Bild des Benutzers gaston-hillar

John, The answer is no. That's explained in the problem definition: "Keywords arent valid for variable names." So, var var = 1; is a syntax error.

For example, we won't accept output as a variable name
because output is an statement for our language.

We won't accept pow as a variable name. We won't accept
var as a variable name.

In order to make it simpler, the following aren't valid
variable names:

var

free

string

output

pow

sqrt

Gastón C. Hillar
Bild des Benutzers john_e_lilley

Excellent, thank you

Melden Sie sich an, um einen Kommentar zu hinterlassen.