HigherOrderCO
read terms directly from hvmc nets
This PR, along with its counterpart, #271 finish the work @FranchuFranchu started to remove the intermediate INet representation (last commit: https://github.com/HigherOrderCO/hvm-lang/commit/7a57879efa0ea4b9352edfb66f2605dac3e34135).
Currently, only linear readback uses the loaned-based algorithm. Non-linear readback uses the old algorithm with a HashMap of uplinks instead of the INet representation. I think there may be a way to use a similar algorithm for non-linear readback, but I'm not sure exactly how it might work.
This new algorithm for linear readback also makes it more powerful; it is now able to read back more of the net. For example, @x let * = (x 123); 0 would previously be read back as @x 0 (which is notably non-linear).
Marking this as draft because I haven't read through the full diff yet, but it should be reviewable.
The first 3 commits reorganize/add some tests; if you're curious to see how the snapshots changed with this new algorithm, you'll want to exclude those commits from the diff.
[@FranchuFranchu I'd be curious to get your thoughts]
@FranchuFranchu I'd be curious to get your thoughts
The code looks great to me; it's like the old pattern refactor branch, but cleaner (and clearer!).
We should keep only one of the two approaches
What do you mean? Like, only keep linear or non-linear?
We should keep only one of the two approaches
What do you mean? Like, only keep linear or non-linear?
I mean use only one approach to do both linear and non-linear. I don't think it's good to have two different readback algorithms coexisting in the repo, it just complicates things.
Well, the current algorithm for linear readback does not work in all cases (it at times omits significant parts of the net), and I don't know yet how to use the new algorithm for non-linear readback, so I'm not sure if that's possible atm.
The PR is looking good, but I'll hold it until I finish porting things to hvm32
This wasn't merged since it doesn't do the non-linear readback (replacing dup variables by the term they're duplicating), which for users is the most regular way of looking at the result.
I still want to incorporate this into Bend, but I'll close the PR since it's going to conflict with so many things we probably want to refactor all the changes.