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

gfiltermap can result in inconsistent graph. #93

Open
kindaro opened this issue Oct 27, 2019 · 1 comment
Open

gfiltermap can result in inconsistent graph. #93

kindaro opened this issue Oct 27, 2019 · 1 comment

Comments

@kindaro
Copy link

kindaro commented Oct 27, 2019

Consider this code:

isLeaf :: Context a b -> Bool
isLeaf (_, _, _, [ ]) = True
isLeaf (_, _, _, _  ) = False

tearLeaves = let p x = if isLeaf x then Nothing else Just x in gfiltermap p

Example:

λ dag3           
mkGraph [(1,'a'),(2,'b'),(3,'c')] [(1,3,())]
λ tearLeaves dag3
mkGraph [(1,'a')] [(1,3,())]

As you see, we obtain a hanging edge.

I propose gfiltermap is improved so that validity of graphs is preserved.

@kindaro
Copy link
Author

kindaro commented Jul 8, 2020

Another example is gmap. Its behaviour depends on the order of traversal and does not make sense overall. For example, the last context to be traversed would always appear to be a leaf.

This can be remedied by making GDecomp an instance of comonad. gmap can then be defined in terms of extend on non-empty graphs, and the definition for an empty graph is trivial to add. I rolled it out at home and it seems to work.

So, in principle it is not a problem to define reasonable maps, therefore I think it is fair to say that we have a bug. I should like to contribute some code to remedy this situation if the maintainers are willing to review and merge.

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

No branches or pull requests

1 participant