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

Adding an interpreter to lcalc #432

Merged
merged 12 commits into from
Apr 7, 2023
Merged

Conversation

adelaett
Copy link
Collaborator

work in progress: I have some issues with GADT

@adelaett adelaett changed the title Adding an interpret to lcalc Adding an interpreter to lcalc Mar 20, 2023
@adelaett
Copy link
Collaborator Author

I've implemented the correct behavior. @AltGr could you take a look to the typing errors?

adelaett and others added 6 commits April 5, 2023 10:32
I made some changes in the meantime, and had to factorise e.g. the handling of
the `EEmptyError` case, but this is the simple approach type-wise of making the
function type for `∀ 'a. 'a —> 'a` (with `assert false` match cases), then
restricting its type do `dcalc` or `lcalc` in the `.mli`.
@adelaett adelaett marked this pull request as ready for review April 5, 2023 10:10
Copy link
Collaborator Author

@adelaett adelaett left a comment

Choose a reason for hiding this comment

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

Thanks @AltGr for this contribution. Is it possible to rework a little bit the cli frontend so we can do catala interpret --lcalc blabla.catala_en or catala interpret --dcalc blabla.catala_en ?

compiler/shared_ast/interpreter.mli Outdated Show resolved Hide resolved
compiler/shared_ast/interpreter.ml Show resolved Hide resolved
compiler/shared_ast/interpreter.ml Outdated Show resolved Hide resolved
@AltGr
Copy link
Contributor

AltGr commented Apr 5, 2023

Thanks @AltGr for this contribution. Is it possible to rework a little bit the cli frontend so we can do catala interpret --lcalc blabla.catala_en or catala interpret --dcalc blabla.catala_en ?

It would probably be simpler to just add a toplevel interpret-lcalc command ?

Copy link
Contributor

@denismerigoux denismerigoux left a comment

Choose a reason for hiding this comment

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

Nice job @adelaett!

@@ -58,6 +60,7 @@ let backend_option_to_string = function
let backend_option_of_string backend =
match String.lowercase_ascii backend with
| "interpret" -> `Interpret
| "interpret_lcalc" -> `Interpret_Lcalc
Copy link
Contributor

Choose a reason for hiding this comment

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

This new backend should be documented in the info variable in this file (around line ~300).

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've added a docstring. Can you confirm it is ok?

Expr.map_raw ~fop:Operator.translate
~floc:(function _ -> .)
~f:(translate_expr ctx) (Marked.mark m e)
| EOp { op; tys } -> Expr.eop (Operator.translate op) tys m
Copy link
Contributor

Choose a reason for hiding this comment

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

You're changing the behavior of your compilation pass here, is this wanted?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We now have a different Expr.map function that don't required anymore the fop and floc functions. Hence, the behavior is the same for the lines you underlined.

"Expected a boolean literal for the result of this assertion \
(should not happen if the term was well-typed)")

let interpret_program_lcalc p s : (Uid.MarkedString.info * ('a, 'm) gexpr) list
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you really have to duplicate the code for interpret_program_lcalc and interpret_program_dcalc ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes there is typing issues. From the discussion with @AltGr, we concluded we need two differents functions.

@denismerigoux
Copy link
Contributor

Perfect, we can merge once CI is green on my side.

@denismerigoux denismerigoux merged commit 7c68af0 into master Apr 7, 2023
adelaett pushed a commit that referenced this pull request Apr 12, 2023
@denismerigoux denismerigoux deleted the adelaett-lcalc-interpret branch May 24, 2023 20:14
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