Skip to content

Parsing ambiguity remains unsolved #172

Closed
@yanliu18

Description

@yanliu18

The existing implementation of the mir parser failed at resolving parsing ambiguities, for example, EnumConstruct vs BinaryOperation.

All the following mentioned branches tested on k v6 installed via kup.

At the master branch, the parser failed at parsing the arithmetic-simple.mir, though kmir run is successful due to disambiguity rules.

At the feature/basic-operations branch, with added CheckedBinaryOp implemented in the same fashion, the parsing and execution failed due to parsing ambiguity. In particular, the execution was stuck at an intermediate result (only appears on linux machine not reproducible on mac, I am confused here. It might be the caching problem that I have been struggling with) like

_2 = amb ( amb ( Add ( const 1_usize , const 1_usize , .OperandList ) , Add ( const 1_usize , const 1_usize ) ) , Add ( const 1_usize , const 1_usize ) ) 

At the refactor/builtin-identifiers branch, I have attempted to implement the built-in functions as tokens, eliminating disambiguity rules. It has no parsing failures except when the variable name clashes with built-in functions (#171 ). I tend to go with this option where it seems straightforward for me (And definitely, there will be more work todo to make the test happy). However, I am unsure if any of you @geo2a and @virgil-serbanuta have tried this option before.
Is there any reason you choose to implement the solution on the master branch instead of this one? Any comments?

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingmir-parserMIR syntax in Kmir-semanticsMIR semantics in K

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions