The `mforeachAux` function was keeping two references to the array
because it was implemented using `miterate a ⟨a, rfl⟩ ...`
Thus, we would have to allocate a new array even if `a` was not shared.
Another issue is that when invoking `x ← f i v`, the array would still
have a reference to `v`, and consequently `RC(v) > 1`, and `f` would not
be able to perform destructive updates to `v` or reuse its memory cell.
Thus, I removed `mforeach` (we only used it to implement `hmap`: the
homogeneous map), and implemented a new `hmap` which makes sure
destructive updates can be performed modulo the issue with float `let`
inwards I described in the previous commit.
@kha I found the problem described in the previous commit when I was
using `Array.hmap`. If we use `Array`s to implement `Syntax` as we discussed,
then a `hmap` that does not prevent destructive updates from happening is
a must-have. Otherwise, any benefit we get from using `Array`s instead
of `List`s is gone.
@kha I renamed the homogeneous `map` to `hmap`, and added the
heterogeneous one as `map`. As soon as we add user-defined rewriting
rules, we will be able to replace `map` with `hmap` whenever the types
are the same.
This commit adds the auxiliary function `expand` to break a nasty
interaction between code specialization, erasure and memory reuse.
Suppose we have
```lean
let new_array := array.update array i v in
have pr : <some property that mentions array>, from <proof>,
f new_array pr
```
Suppose `f` is not marked with `[specialize]`. Then, `pr` is erased and we get:
```lean
let new_array := array.update array i v in
f new_array box(0)
```
If `RC(array) == 1`, then the update performs a destructive update, and
we are happy.
Now, assume that `f` is marked with `[specialize]`.
Moreover, function specialization occurs before erasure since we want to
be able to use the to-be-implemented user-defined rewriting rules after specialization.
When we specialize `f` we compute a closure of its dependencies, and one of them is array because of `pr`.
Thus, we get
```lean
let new_array := array.update array i v in
f_spec new_array array
```
after specialization and erasure, but now, we don't perfom the destructive update.
BTW, I assumed we should be able to reduce the arity of `f_spec` after
erasure since the parameter `array` be dead after it. However, I found the following TODO:
https://github.com/leanprover/lean4/blob/master/src/library/compiler/reduce_arity.cpp#L50
A few commits ago, a few `RBMap` and `RBTree` functions had
the parameters `(lt : a -> a -> Prop) [DecidableRel lt]` instead of
`(lt : a -> a -> Bool)`. Recall that the compiler automatically specializes
functions with arguments of the form `[ ... ]`. Thus, after we moved to
`(lt : a -> a -> Bool)` we have to include `@[specialize]` to force the
compiler to specialize.
`mfor` was creating a bunch of closures.
We have disabled `mrepeat` since we don't have support for marking
which arguments should be considered during specialization.
Old `Nat.repeat` => `Nat.for`
Old `Nat.mrepeat` => `Nat.mfor`
New `Nat.repeat` has type
```
def repeat {α : Type u} (f : α → α) (n : Nat) (a : α) : α :=
``
`List.repeat` => `List.replicate` (like in Haskell)
Avoid weird `ℕ` in List library
The new `partial def`s allow us to define `fix` in Lean, but the Lean
implementation is not as efficient as the native one. The native one
in C++ use weak pointers to prevent a closure allocation at every
recursive invocation.
This commit also fixes the `fixCore` helper functions that were broken
after we switched to camelCase.
We have updated the test `fix1.lean` to demonstrate the native
implementation is faster. Here are the numbers on my desktop.
```
./run.sh fix1.lean 24
721420279
Time for 'native fix': 816ms
721420279
Time for 'fix in lean': 1.34s
```
