Skip to content

Arch refactor typechecker#414

Draft
pataei wants to merge 25 commits intomainfrom
arch-refactor-typechecker
Draft

Arch refactor typechecker#414
pataei wants to merge 25 commits intomainfrom
arch-refactor-typechecker

Conversation

@pataei
Copy link
Copy Markdown
Collaborator

@pataei pataei commented Mar 30, 2023

@hackedy and @jnfoster Submitting this PR for review of surface IR, after the review I'll make this a draft PR. So please don't merge this.

The main goal of the IR is:

  • to be simple.
  • to represent P4 programs before and after type inference and cast insertion (notice the type for type_params which is P4String * option type, where the option type will be initiated to none after parsing and after type inference, it will be replaced with the inferred type.

@pataei pataei requested review from hackedy and jnfoster March 30, 2023 00:54
@jnfoster
Copy link
Copy Markdown

jnfoster commented Mar 30, 2023

Hi Parisa,

I took a look at this. It is still parameterized by a tags_t type. So, unless I misunderstood, the refactor seems possibly incomplete?

Could you go through the whole IR and:

  • Add parsing info everywhere (and I do mean pretty much everywhere -- even ints, strings, operators, etc.)
  • Add an optional type where appropriate (again pretty much everywhere, but some terms may not need types).

@jnfoster
Copy link
Copy Markdown

Another thing to consider: we may want to inline the parsing info and optional type into every constructor rather than using the "X" and "PreX" scheme.

If you do this, use a consistent names and always include those fields as the first 2 (or 1 if no type is needed) elements.

Copy link
Copy Markdown
Collaborator

@hackedy hackedy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. I left some comments we can talk about today

(typ: typPreT)
with typVarTyp := (*type variable or their assignment*)
| TypVarTyp (type_var: P4String)
(type: option typ)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think typVarTyp shouldn't exist and uses of typVarTyp should just be bare p4strings. Type variables should be filled in by introducing TypSpecialization nodes, not by modifying type variable nodes to include a binding.

Copy link
Copy Markdown
Collaborator Author

@pataei pataei Apr 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but we can't access the binding of type variables within a type without accessing the context and the idea is to instantly access the binding of variables within a type.

(code: block)
| StmtSwitchCaseFallThrough (tags: tags_t)
(lable: stmtSwitchLabel)
with statementPreT := (*why surface.ml has declaration in statements and p4light has variable and instantiation in it? *)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can just do variables and instantiations and not full declarations, the parser I think enforces that the only declarations allowed in statement contexts are variables and instantiations anyway

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already resolve this, but probably forgot to remove this comment in the code. I'll keep it as the declaration in statement since the parser enforces them to be either variables or instantiations.


Section Syntax.

Context {tags_t: Type}.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's get rid of tags_t and use parsing info (I think Info.t or P4Info is the name in the codebase) everywhere we use tags_t

(typ: typ) (*surface*)
(default_value: option expression)
(variable: P4String)
with expressionPreT :=
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should expressions have (optional) type annotations?

Copy link
Copy Markdown
Collaborator Author

@pataei pataei Apr 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean parameters? expressions do have optional types but parameter's type shouldn't be optional.


Variant fieldType :=
| FieldType (typ: typ) (*surface*)
(field: P4String).
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not use P4String.AList tags_t typ instead of list fieldType?

(matches: list tableOrParserMatch)
(next: P4String).

Variant methodPrototype :=
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indent

(args: list argument)
| StmtAssignment (lhs: expression)
(rhs: expression)
| StmtdirectApplication (typ: typ) (*surface*)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

caps on Direct

@hackedy
Copy link
Copy Markdown
Collaborator

hackedy commented Apr 6, 2023

Does this PR fix #5? Can we make sure it does?

@pataei
Copy link
Copy Markdown
Collaborator Author

pataei commented Apr 6, 2023

Does this PR fix #5? Can we make sure it does?

Yes, the statement now only allows constant, variable, and instantiation declarations.

@pataei pataei marked this pull request as draft April 14, 2023 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants