-
Notifications
You must be signed in to change notification settings - Fork 1
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
Divisible/Decidable instances for DA #8
Comments
I suppose it is also worth me mentioning/considering that the type variable order here for -- could define new type like this
data DA s q =
DA { output ∷ q → Bool
, transition ∷ q → (s → q)
}
-- (or even avoid that and just do a type level flip) Although that would require some fancy work to map over states because a |
Looked at this for a bit today, seems like bisimulation/perfect-shuffle and shuffle for
Looks like what I want :) See 3.3 slide 18: https://liacs.leidenuniv.nl/~hoogeboomhj/second/secondcourse.pdf Next I think I want to better understand shuffle in terms of the unique morphism from the final automaton of languages. See Section 7: |
(17) and (18) from https://homepages.cwi.nl/~janr/papers/files-of-papers/1998_CONCUR_automata_and_coinduction.pdf This is in fact equivalent to the following classical theorem by Nerode and Myhill. v Rₗ w iff ∀ u ∈ A*, vu ∈ L ⇔ wu ∈ L |
Some properties of shuffle: |
Unicode for shuffle: ⧢ "Shuffe factorization is unique" :) And: u ⧢ ε = ε ⧢ u = u One question I need to resolve is the identity. |
I can write code which type checks for these instances (see below) but I need to explore what the correlations are and what the interpretation should be to operations on regular languages. For example,
contramap
is quite close to the definition of inverse homomorphism of a regular language (a constructive proof is typically given for DFA), except that the morphism function is usually given in textbooks as(s → [g])
or sometimes equivalently([s] → [g])
. I'm not sure it's okay to say contramap would suffice for invhom despite being polymorphic because morphisms which "erase" might be troublesome. Even if we let the co-domain of h be some finite list type for example, I think it would still need a way toconcat
, or perhaps it would not matter, I'll have to think more about that.May also want to consider making a data type for semi automata in case there are multiple good interpretations each with different
output
definitions. But that is just speculation for now.The text was updated successfully, but these errors were encountered: