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.

Sign up for GitHub

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

BTrees in Motoko. #396

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from
Draft

BTrees in Motoko. #396

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
c35b3d9
BTree.
matthewhammer Jun 23, 2022
b95320f
remove already-stale invariants comment. prefer Check module.
matthewhammer Jun 23, 2022
d81a1c3
revised definition. wrote find. checks need revision.
matthewhammer Jun 24, 2022
142a0d0
simplify type defs.
matthewhammer Jun 24, 2022
ffd99ec
adjust Check module.
matthewhammer Jun 24, 2022
61334ec
fix issues and unit test.
matthewhammer Jul 16, 2022
0d06506
missing file: BTreeTest.mo
matthewhammer Jul 16, 2022
273fb6f
simpler public API; unit test for find.
matthewhammer Jul 16, 2022
9db84ca
internal compiler error. const ... captures ..., not found in static …
matthewhammer Jul 19, 2022
4393a81
workaround compiler issue.
matthewhammer Jul 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions src/BTree.mo
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,19 +34,19 @@ module {
#leaf : Data<K, V>;
};

func find_data<K, V>(data : Data<K, V>, find_k : K, c : Compare<K>) : ?V {
func find_data<K, V>(data : Data<K, V>, find_k : K, c : (K, K) -> Order.Order) : ?V {
for ((k, v) in data.vals()) {
if (c.compare(k, find_k) == #equal) { return ?v };
if (c(k, find_k) == #equal) { return ?v };
};
return null
};

func find<K, V>(t : Tree<K, V>, k : K, c : Compare<K>) : ?V {
switch t {
public func find<K, V>(t : Tree<K, V>, k : K, c : (K, K) -> Order.Order) : ?V {
switch t {
case (#leaf(d)) { return find_data<K, V>(d, k, c) };
case (#internal(i)) {
for (j in I.range(0, i.data.size())) {
switch (c.compare(k, i.data[j].0)) {
switch (c(k, i.data[j].0)) {
case (#equal) { return ?i.data[j].1 };
case (#less) { return find<K, V>(i.trees[j], k, c) };
case _ { }
Expand Down
17 changes: 15 additions & 2 deletions test/BTreeTest.mo
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,10 @@ import BT "mo:base/BTree";
import Nat "mo:base/Nat";
import Text "mo:base/Text";

import Suite "mo:matchers/Suite";
import M "mo:matchers/Matchers";
import T "mo:matchers/Testable";

Debug.print "BTree tests: Begin.";

func check(t : BT.Tree<Text, Nat>){ BT.Check.root<Text, Nat>({compare=Text.compare; show=func (t:Text) : Text { t }}, t) };
Expand All @@ -21,7 +25,7 @@ check(leaf_of_one);

Debug.print "leaf of two.";
let leaf_of_two = #leaf([("ash", 1), ("oak", 2)]);
check(leaf_of_one);
check(leaf_of_two);

Debug.print "leaf of three. A-C";
let leaf_of_three_a_c = #leaf([("apple", 1), ("ash", 4), ("crab apple", 3)]);
Expand All @@ -32,6 +36,15 @@ let leaf_of_three_s_w = #leaf([("salix", 1), ("sallows", 4), ("willow", 3)]);
check(leaf_of_three_s_w);

Debug.print "binary internal.";
check(#internal({data=[("pine", 42)]; trees=[leaf_of_three_a_c, leaf_of_three_s_w]}));
let binary_internal = #internal({data=[("pine", 42)]; trees=[leaf_of_three_a_c, leaf_of_three_s_w]});
check(binary_internal);

let _ = Suite.suite("find", [
Suite.test("pine",
BT.find<Text, Nat>(binary_internal, "pine", Text.compare),
M.equals(T.optional<Nat>(T.natTestable, ?42))
)
]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 To using matchers instead of debug statements for tests.

This is the pattern I've been using for my tests.

I create a "suite" for a specific function, like here where I have all of the different test cases for that function inside it.

Then I run the test suite for each function here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 To using matchers instead of debug statements for tests.

For me, it's not one or the other. It's "which here?" -- Like all tools and techniques, there is a place for matches, but it's not a universal solution, or even close to one.

For instance, what value would it add to the first tests, where I just want to define a bunch of trees using let expressions that scope in a nested way, and assert that they are valid? To me, plain Motoko is the right structure for that test, and I used Debug prints so I know where I am in that script.

How does matchers help there? I can't see it -- It's not really helping guide that sort of test structure at all, and that's fine. I think it's okay to use it only where it helps --- organizing tests of an API, ensuring that each operation has some coverage. (I plan to use it for the rest of the API coverage tests.)



Debug.print "BTree tests: End.";