Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arch refactor typechecker #414

Draft
wants to merge 25 commits into
base: main
Choose a base branch
from
Draft

Arch refactor typechecker #414

wants to merge 25 commits into from

Conversation

pataei
Copy link
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
Contributor

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
Contributor

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
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
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
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
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
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
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
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
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
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
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
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
Collaborator

hackedy commented Apr 6, 2023

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

@pataei
Copy link
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