<< Back to previous view

[UNIFY-6] Create tests for k&v map unification Created: 25/May/12  Updated: 25/May/12

Status: Open
Project: core.unify
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Fogus Assignee: Fogus
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Substitution in map keys or values should both work. I doubt there are tests around this.






[UNIFY-3] Enhance documentation Created: 03/Feb/12  Updated: 03/Feb/12

Status: Open
Project: core.unify
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Fogus Assignee: Fogus
Resolution: Unresolved Votes: 0
Labels: docs


 Description   

The current unify docs are spartan and "just the facts". It would be useful to have a set of docs that:

  • explain unification
  • explain the library use cases
  • show a simple example use





[UNIFY-9] Between clojure 1.6 and clojure 1.7, unification of maps stopped working correctly Created: 28/Feb/17  Updated: 01/Mar/17

Status: Open
Project: core.unify
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jason Felice Assignee: Fogus
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Failure duplicated on clojure 1.7, clojure 1.9.0-alpha14.
Does not fail on 1.5.1, 1.6.



 Description   

With 1.9.0-alpha14:

dev=> (clojure.core.unify/unify {:a '?x, :c :d} {:c :d, :a :b})
nil
dev=> (clojure.core.unify/unify {:a '?x, :c :d} {:a :b, :c :d})
{?x :b}


 Comments   
Comment by Jason Felice [ 01/Mar/17 10:47 AM ]

There's an indication in UNIFY-6 that we expected this to work, although the current algorithm never supported variables in keys. It did unify values of like keys, but it relied on two maps with the same key sets having the same iteration order. That's what broke.

An easy fix would be to restore the previous behavior–the previous behavior was O (relying on iteration over map keys being O for their current order), and the easy fix would make it something like O(n log_32 n) for maps.

A more interesting fix would be to add support for variables in keys. This is something I find valuable (and interesting). This changes the algorithm because the lack of order of a set makes multiple unifications possible, e.g. (unify {:a 1, :b 2} {?x _, ?y _}) has two unifications: {?x :a, ?y :b} and {?x :b, ?y :a}, and therefore backtracking (or something like it) becomes necessary.

This same mechanism could be used for sets, as reported in UNIFY-8.

Would the "interesting" fix be considered, or should I just go for "easy"?





[UNIFY-7] Dead code in occurs? function Created: 28/Jul/13  Updated: 28/Jul/13

Status: Open
Project: core.unify
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Greg Chapman Assignee: Fogus
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In the cond in the occurs? function, this condition:

(zip/end? z) false

appears twice. Unless I very much misunderstand, the second clause will never succeed.

Also, I'm wondering if it makes sense (in core.unify) for composite? to be true for strings. It looks like this means occurs? will futilely check each character of a string looking for variables.






[UNIFY-8] Handle sets correctly Created: 21/May/14  Updated: 21/May/14

Status: Open
Project: core.unify
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Pascal Germroth Assignee: Fogus
Resolution: Unresolved Votes: 0
Labels: None
Environment:

unify 0.5.5



 Description   

Currently unify allows using sets as expressions and just uses them as sequences, which, depending on the order of items, causes the unification to fail or succeed:

(unify #{ '[aa a] '[bb b] } ; =seq=> [bb b] [aa a]
       #{ '[?a a] '[?b b] } ; =seq=> [?b b] [?a a]
) ; => {?a aa, ?b bb}
(unify #{  '[a a]  '[b b] } ; =seq=> [a a] [b b]
       #{ '[?a a] '[?b b] } ; =seq=> [?b b] [?a a]
) ; => nil, expected {?a a, ?b b}

Unify should either handle sets (not sure if the algorithm allows for that easily) or throw an IllegalArgumentException when passed a set, but not silently seq it and behave unpredictably like that.






Generated at Thu Apr 27 06:24:02 CDT 2017 using JIRA 4.4#649-r158309.