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

Various fixes #2

Open
wants to merge 17 commits into
base: master
Choose a base branch
from
Open

Various fixes #2

wants to merge 17 commits into from

Conversation

polytypic
Copy link

@polytypic polytypic commented Jun 28, 2020

Here are some fixes I've accumulated while toying with 1ML.

See the individual commits for some details. One of the commits adds Travis CI integration (i.e. it is not a fix).

Sorry, @rossberg, for dumping these all at once. I can spend some time reworking this PR if you like.

The `HOLE` rule is now only a part of path expressions.  Removing the duplicate
rule resolves a ton of reduce-reduce conflicts in the grammar.
...so that they can be pattern matched.
When determining whether a type contains a variable any undetermined inferred
type may end up containing the variable.
The original code simply used a wrong variable in place of the field name.
See rule EUNWRAP in fig 9 in section 5.1 of JFP (draft) paper
and rule EIF in fig 8 in section 4.2 of JFP (draft) paper.
Previously `annotP` only equated the types in the case when there was a sequence
of bindings produced by the nested patterns.  This meant that inconsistent
patterns would type check.  For example, before this PR, the REPL interaction

    1ML> ({}: int) = 1;

    1ML> ((x: int): text) = "1";
    x : text

would not give errors.  After this PR, the same interaction

    1ML> ({}: int) = 1;
    stdin:1.2-1.9: inconsistent types equated by `as': () vs int
    1ML> ((x: int): text) = "1";
    stdin:1.6-1.16: inconsistent types equated by `as': int vs text

gives reasonable errors.
Especially in the case of Set and Map abstractions that are supposed to use
given ordering.
@rossberg
Copy link
Owner

rossberg commented Jul 3, 2020

Wow, thanks! I'm on vacation right now, so only skimmed through so far. Some changes obviously make sense, some I'll need to think about (and swap in all the background first). So, yeah, it might help to split this up a little, e.g., one PR with all the obvious fixes, and then separately the others.

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.

2 participants