victorcmiraldo / hdiff Goto Github PK

(very loose notes follow)

Sharing is a constant complication and advantage of the hdiff approach.
We do see interesting things related to it, for example, patches have some sort of
eta-inequality:

[0] -|+  Bin [0] Leaf  > Bin [0] [1] -|+ Bin (Bin [0] [1]) Leaf

This has implication on merging, for example.

One option for controlling sharing can be seen in here, where we pass around a function
that decides to add some prefix to the hash of certain AST elements. The big issue is that
if we rename a function, we loose sharing of its contents.

I'd like to have a better story here. How to actually control that we want to share all the variables named "aux" that occur inside the same function, but not outside the function scope, for example.
Naturally, this has to be resistent to function renaming. Upon seeing a rename, we must be
able to detect that the body should be shared.

Because we are parsing the result of the merge too late, we are getting a different number of parse-errors:

Say that m = nonest and h=1 solves the conflict; this means that here we will try and parse M.lang;
which can raise a parse error.

Now say that m = proper didn't solve the conflict; we exit at once.

We have already implemented tree edit distance; We already seen how a HDiff.Patch translated
to a GDiff.ES is worse, in terms of higher edit-script-cost, than a computed GDiff.ES.

Another thing we should do is count how many constructors we actually delete and insert
with a HDiff, and compare that with a gdiff. For that to be accurate, though, we must
not count the spine:

hdiffCost :: Patch -> Int
hdiffCost p = sum . holesGetHolesWith (uncurry' go) . holesLCP (cCtxDel (distr p)) (cCtxIns (distr p))
  where
    go p q = size p + size q

We should be calling ulimit -m; The -v option is for virtual memory

There is a number of things that require attention on the metatheoretical level.

First and foremost, definition of \subseteq for patches, secondly, thin operator.
Then, we'd like to know whether they are related or not. Hopefully, this informs us enough to
know whether copies closer to the root are better than more copies further down the tree with contractions.

diff (Bin (Bin t k) u) (Bin (Bin t k) t)

It is very common to ues code such as:

... $ utxMap f $ utxLCP p q

which can be fused with a better utxLCPWith:

... $ utxLCPWith f p q

utxLCPWith :: (forall at . UTx phi at -> UTx psi at -> res at)
                   -> UTx phi at -> UTx psi at -> UTx res at

utxLCP = utxLCPWith (:*:)

Another pattern we can optimize is the

... $ foldr f e $ utxGetHolesWith' g p

a = "i" :>: []
b = "l" :>: ["i" :>: [],"c" :>: []]
c = "b" :>: ["c" :>: [],"f" :>: []]

ab = distrCChange $ hdiffRTree a b
bc = distrCChange $ hdiffRTree b c

infinite_loop_in = ab `after` bc

That's because as of c7d4232 , after is implemented
with thinning; and thinning loops when variable names are repeated; I need to look into this and make
it better.

http://hackage.haskell.org/package/unbound-0.5.1.1/docs/Unbound-LocallyNameless.html#t:Name

Seems like some changes are self contained, and could be seen as a closed lambda term.

todo: distinguish between open and closed changes.

Hey!

Is this the repo for your ICFP2019 paper? I don't think it's released to Hackage yet.

Cheers!