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

unification environment #18

Open
kowey opened this issue Mar 4, 2013 · 4 comments
Open

unification environment #18

kowey opened this issue Mar 4, 2013 · 4 comments
Assignees

Comments

@kowey
Copy link
Owner

kowey commented Mar 4, 2013

OK, it doesn't have to be a monad. But I want to have some sort of abstraction that guarantees that when I do unification on something, the results from previous unification will be automatically propagated to that thing. Seems like it should be fairly straightforward. You could just model this as a state monad for example, and have the unification function get/put the substitutions state.

What may be annoying is having to write a monad transformer and slip it into our current MT stack.

The goal is to have something that makes our code easier to write, and less error-prone, while also staying cheap (we shouldn't be doing any needless traversals).

@ghost ghost assigned kowey Mar 4, 2013
@kowey
Copy link
Owner Author

kowey commented Mar 4, 2013

Imported from trac issue 18. Created by kowey on 1970-01-01T01:20:48, last modified: 1970-01-01T01:20:48

@kowey
Copy link
Owner Author

kowey commented Mar 4, 2013

Renamed from monad to environment. I don't care how it's implemented, I just want a less error-prone way to do unification. The standard approach of unification variables pointing into a common environment might be better.

@kowey
Copy link
Owner Author

kowey commented Mar 25, 2013

Phew, the way we're doing unification really is dreadful. And an environment doesn't sound so hard either.

@kowey
Copy link
Owner Author

kowey commented Mar 31, 2013

OK, have a rough idea what to do maybe.

So problem is bugs caused by forgetting to replace, or not replacing on parent structure

Possible solution: anything with unification variables must have an environment (Var to Value). Let's call it U a. Unifying is U a -> U a -> U a

That is rather than running the replacements, you just have to swap the environments out. But forgetting to swap the environments can still be bad. Maybe this is where something like monads or something could be good? If you have some

data BigThing = BigThing
      { small :: SmallThing
      , etc :: Etc }

When you do unification on the SmallThing, one way or another we need to make sure the rest of BigThing receives the right values. So nebulous idea is that you would do unify :: U SmallThing -> U SmallThing -> U SmallThing and somehow go from there to U BigThing. How do we ensure the right environment?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant