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

Translate FST to VariantList and disprove translation to OC #35

Merged
merged 21 commits into from
May 27, 2024

Conversation

ibbem
Copy link
Collaborator

@ibbem ibbem commented May 20, 2024

No description provided.

@ibbem ibbem force-pushed the translate-from-FST branch from a0eb03f to 0b3868b Compare May 20, 2024 21:55
Copy link
Member

@pmbittner pmbittner left a comment

Choose a reason for hiding this comment

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

Hi @ibbem,

thank you for the proofs! I appreciate the documentation for the proof idea of FST -/-> OC but was left a bit confused.

data MaybeSubtree {A : 𝔸} : Maybe (Rose ∞ A) → Maybe (Rose ∞ A) → Set₁ where
neither : MaybeSubtree nothing nothing
one : {c : Rose ∞ A} → MaybeSubtree nothing (just c)
both : {c₁ c₂ : Rose ∞ A} → Subtree c₁ c₂ → MaybeSubtree (just c₁) (just c₂)
Copy link
Member

Choose a reason for hiding this comment

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

Please document the purpose of this predicate.

both : {c₁ c₂ : Rose ∞ A} → Subtree c₁ c₂ → MaybeSubtree (just c₁) (just c₂)

Implies : {F : 𝔽} → Configuration F → Configuration F → Set
Implies {F} c₁ c₂ = (f : F) → c₁ f ≡ true → c₂ f ≡ true
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if this theorem could be generalized to any configuration language. We have a similar relation for configurations defined for the ADT translation, based on paths. There is nothing to change here. I was just wondering.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The predicate Implies could indeed be generalized for any configuration which is a function to Bool (e.g., 2CC). However, the subtree theorem is false for any other language in our language map except FST because they can encode alternatives. Alternatives do invalidate this theorem because setting a feature to false can add new subtrees.

I have search a bit in the standard library right now but didn't find a definition which fits Implies nicely. However there is _≤_ in Data.Bool which we could reuse. Do you think this is a good idea? The new definition would be

Implies : {F : 𝔽}  Configuration F  Configuration F  Set
Implies {F} c₁ c₂ = (f : F)  c₁ f ≤ c₂ f

I haven't yet investigated how the proofs would change if we adopted _≤_.

Copy link
Member

Choose a reason for hiding this comment

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

Oh interesting! Maybe it would make sense to turn what you wrote here into a comment on this predicate.

I do not see a real benefit from using the standard-library here. It does not improve readability and if we do not make use of more features from the STL, it is probably simpler to just stick to what we have currently.

... | .nothing | just c' | one = c' ∷ʳ subtreeₒ-recurse cs c₁ c₂ c₁-implies-c₂
... | .(just _) | .(just _) | both p = p ∷ subtreeₒ-recurse cs c₁ c₂ c₁-implies-c₂

subtree : ∀ {F : 𝔽} {A : 𝔸} → (e : WFOC F ∞ A) → (c₁ c₂ : Configuration F) → Implies c₁ c₂ → Subtree (⟦ e ⟧ c₁) (⟦ e ⟧ c₂)
Copy link
Member

Choose a reason for hiding this comment

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

That's a great theorem. :) Can you add a short documentation (including a short description on why this is true)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Is it enough to add documentation to subtree or should subtreeₒ and subtreeₒ-recurse also have documentation?

Copy link
Member

Choose a reason for hiding this comment

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

I guess the more the better. It is probably hard to document subtree's workings without documenting the other two functions? 🤔

src/Translation/Lang/FST-to-OC.agda Outdated Show resolved Hide resolved
src/Translation/Lang/FST-to-OC.agda Outdated Show resolved Hide resolved
src/Translation/Lang/FST-to-OC.agda Outdated Show resolved Hide resolved
src/Translation/Lang/FST-to-OC.agda Outdated Show resolved Hide resolved
shared-artifact (f OC.❲ e ❳) c₁ c₂ p₁ p₂ with c₁ f | c₂ f
shared-artifact (f OC.❲ e ❳) c₁ c₂ p₁ p₂ | true | true = shared-artifact e c₁ c₂ p₁ p₂

-- This is the main induction over the top most children of the OC expression.
Copy link
Member

Choose a reason for hiding this comment

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

Great! :) Can you again shortly phrase what it is that we prove with this induction? This theorem is not obvious and it is not the final result yet.

-- all true configuration.
--
-- If an option evaluates to an artifact for both `c₁` and `c₂` it must also
-- evaluate to an artifact for the intersection of these configurations. The
Copy link
Member

Choose a reason for hiding this comment

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

"interesection" in terms of _∧_ right?

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.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe add a short comment for that: (in terms of _∧_).

@@ -269,6 +270,15 @@ module Completeness {F : 𝔽} (f : F × ℕ → F) (f⁻¹ : F → F × ℕ) (f

OC-cannot-be-compiled-to-FST : ¬ (LanguageCompiler (WFOCL F) (FSTL F))
OC-cannot-be-compiled-to-FST = compiler-cannot-exist FST-is-less-expressive-than-OC

module _ {F' : 𝔽} (f₁ f₂ : F') (f₁≢f₂ : f₁ ≢ f₂) (_==ꟳ_ : DecidableEquality F') where
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we should shortly document here what these assumptions are and why they are reasonable. String and Nat obviously satisfy them.

@pmbittner
Copy link
Member

I still have to review the last commit [Translate FST to VariantList](https://github.com/pmbittner/AgdaCCnOC/pull/35/commits/0b3868b08c86cc7df01e2c066c1c3ec96630fb30) but I have to exit my train now. :D

@pmbittner
Copy link
Member

Hi @ibbem ,

thanks for the beautiful translation and proof of FST -> VariantList. I figured it would be easier this time to put my comments directly into the Agda file. I added some documentation but only got through half of the file. I will continue later.

Please have a look at my commit. Is my documentation correct? Also search for @ibbem: It would be great if you could write the documentation in these places.

@pmbittner
Copy link
Member

pmbittner commented May 23, 2024

Also I am experiences build problems with nix currently. I get hundreds of these errors on this branch

/home/paul/projects/AgdaCCnOC/src/MAlonzo/Code/Util/String.hs:112:30: error: [GHC-76037]
    Not in scope:
      data constructor ‘MAlonzo.Code.Relation.Nullary.Decidable.Core.C__because__32’
    NB: the module ‘MAlonzo.Code.Relation.Nullary.Decidable.Core’ does not export ‘C__because__32’.
    Suggested fix:
      Perhaps use ‘MAlonzo.Code.Relation.Nullary.Decidable.Core.C__because__34’ (imported from MAlonzo.Code.Relation.Nullary.Decidable.Core)
    |
112 |                              MAlonzo.Code.Relation.Nullary.Decidable.Core.C__because__32 v5 v6
    |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It seems there are many things in the standard library, which cannot be found.

@ibbem
Copy link
Collaborator Author

ibbem commented May 24, 2024

Also I am experiences build problems with nix currently. I get hundreds of these errors on this branch

This has nothing to do with Nix 😇. It's a cache invalidation problem of Agda. In particular, Agda generated the src/MAlonzo folder which is now out of date. Just delete it. Agda will regenerate it with the updated versions of these files.

@ibbem
Copy link
Collaborator Author

ibbem commented May 24, 2024

I figured it would be easier this time to put my comments directly into the Agda file.

Nice! I think I prefer this way. In contrast to GitHub, I can use all power of Git to look and filter comments. This is especially nice for finding where these comments actually apply because I don't need to move from the GitHub interface to my Editor when I need to address something.

The only drawback is a kind of weird Git history in case you also add change request that way.

@pmbittner
Copy link
Member

pmbittner commented May 24, 2024

Also I am experiences build problems with nix currently. I get hundreds of these errors on this branch

This has nothing to do with Nix 😇. It's a cache invalidation problem of Agda. In particular, Agda generated the src/MAlonzo folder which is now out of date. Just delete it. Agda will regenerate it with the updated versions of these files.

Ok great! I will try that. Maybe this is something for a "Troubleshooting" section for a potential future artifact submission, as well as something work putting into the makefile (make clear). I will do that.

Edit: We already have make clean :)

Edit: This solved the problem indeed.

@pmbittner
Copy link
Member

I figured it would be easier this time to put my comments directly into the Agda file.

Nice! I think I prefer this way. In contrast to GitHub, I can use all power of Git to look and filter comments. This is especially nice for finding where these comments actually apply because I don't need to move from the GitHub interface to my Editor when I need to address something.

The only drawback is a kind of weird Git history in case you also add change request that way.

Ok then let's try this kind of reviews more in the future. Another drawback could be that it might be less transparent for working in parallel. For example, I would like to continue commenting on your PR but I also don't want to introduce merge conflicts. (Maybe though, this problem is less bad as it sounds though.)

@ibbem
Copy link
Collaborator Author

ibbem commented May 24, 2024

I figured it would be easier this time to put my comments directly into the Agda file.

Nice! I think I prefer this way. In contrast to GitHub, I can use all power of Git to look and filter comments. This is especially nice for finding where these comments actually apply because I don't need to move from the GitHub interface to my Editor when I need to address something.
The only drawback is a kind of weird Git history in case you also add change request that way.

Ok then let's try this kind of reviews more in the future. Another drawback could be that it might be less transparent for working in parallel. For example, I would like to continue commenting on your PR but I also don't want to introduce merge conflicts. (Maybe though, this problem is less bad as it sounds though.)

I'm fine with solving such merge conflicts. There shouldn't be too many most of the time because one reviewer will most likely (re-)review parts are new or are changed. Except of course for big changes (e.g., renaming a file, like I will do soon 😅)

@ibbem ibbem force-pushed the translate-from-FST branch from cd3512c to 530470e Compare May 24, 2024 13:18
@ibbem ibbem force-pushed the translate-from-FST branch from c5dd62a to bacf830 Compare May 24, 2024 14:56
@pmbittner
Copy link
Member

Hi @ibbem ,

I just pushed some revisions and TODOs. Please check my additions. Please replace the TODO ibbem commits with commits that resolve the respective TODOs.

If you are done, please merge. I think the PR looks great now. :)

@ibbem ibbem force-pushed the translate-from-FST branch from 58cb9e1 to 3ca7c93 Compare May 27, 2024 21:02
@ibbem ibbem merged commit 7d75889 into develop May 27, 2024
1 check passed
@ibbem ibbem deleted the translate-from-FST branch May 27, 2024 21:13
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