Skip to content
This repository has been archived by the owner on Jun 28, 2023. It is now read-only.

Custom protocol creation #7

Closed
RamonMeffert opened this issue Nov 7, 2020 · 5 comments
Closed

Custom protocol creation #7

RamonMeffert opened this issue Nov 7, 2020 · 5 comments
Assignees
Labels
in progress The issue currently being worked on protocol representation

Comments

@RamonMeffert
Copy link
Owner

I.e. a way to combine constituents in the UI to create a protocol

@RamonMeffert
Copy link
Owner Author

When this is done, it might be a nice idea to integrate a way to simplify protocols (normal forms are probably useful for this). This would then also allow us to check whether a newly created protocol isn't just the same as an older one.

@RamonMeffert RamonMeffert added this to the Showable version milestone Nov 24, 2020
@RamonMeffert
Copy link
Owner Author

@RamonMeffert
Copy link
Owner Author

This'll also end up fixing #24 when I implement the package I mentioned above

@RamonMeffert
Copy link
Owner Author

RamonMeffert commented Dec 2, 2020

(These are basically some notes for myself)

I have a rough draft for a drag-'n-drop system for boolean combinations of gossip protocol constituents that I think is pretty neat, but it needs:

  • validation (so A ∧ B ∨ (C ∧ D) is valid, but A ∧ ∨ (C ∧ D) is not)
    • All constituents or groups must be separated by And or Or
    • Groups should not contain singletons (so don't allow (or at least warn against) (A) ∧ (B) ∧ ((C))
    • Don't allow groups to self-nest by dragging
  • (Possibly) valuation checking to warn against (some) constructions that are impossible, e.g. A ∧ ¬A
  • conversion (i.e. parsing) to usable protocol
  • A way to make groups (i.e. stuff in parentheses) draggable, probably with drag handles
  • A way to restrict grouping depth, so people don't start making protocols like (A ∧(A ∧(A ∧(A ∧(A ∧(A ∧(A ∧(A ∧(A ∧ B)))))))) – that's hard to render

Then, I need to convert the current predefined protocols to the new format.

Currently, I'm using the following type:

type BoolElement 
    = And
    | Or
    | Token Bool Constituent
    | Group Bool (List BoolElement)

The Bools are negation parameters, so Token True IsEmpty would mean σₓ = ϵ and Token False IsEmpty would mean σₓ ≠ ϵ (or ¬(σₓ = ϵ))

Based loosely on the following LL(1) grammar:

Expression   -> Token Expression'
Expression'  -> or Token Expression' | ε
Token        -> Final Token'
Token'       -> and Final Token' | ε
Final        -> Negation Final'
Negation     -> not | ε
Final'       -> ( Expression ) | constituent

Note that the use of Group makes parsing a lot easier. Also, by constraining the type and allowing only certain modifications in the interface, it should be possible to use the validation step to make sure parsing is possible, using a couple of relatively simple rules.

@RamonMeffert
Copy link
Owner Author

Plan for the showable version: Add a note saying that this is in progress w/ a link to (the cleaned up version of) a live version of the repository mentioned above, and include it in the query as a hypothetical

@RamonMeffert RamonMeffert added the in progress The issue currently being worked on label Dec 16, 2020
@RamonMeffert RamonMeffert pinned this issue Dec 16, 2020
@RamonMeffert RamonMeffert unpinned this issue Mar 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
in progress The issue currently being worked on protocol representation
Projects
No open projects
Development

No branches or pull requests

1 participant