e96026651b
@kha I added the `d_array` type that we discussed today. However, the VM implemantion is still using persistent arrays. If we remove the persistent array support, then code using hash_map will only be efficient if the hash_map is used linearly. This is not the case in the reader module because we are planning to support backtracking. On the other hand, it is awkward we currently don't have a vanilla array implementation in the VM. I suspect this will be a problem in the future. So, I see the following possibilities: 1- We implement a map data-structure using red-black trees in Lean. We use this new data-structure to implement all maps in the new reader and macro expander. 2- We implement a very simple map as a list of pairs. Then, we replace it in the VM with an efficient implementation. The VM implementation may use our internal red-black trees. We may also use a persistent hash table implemented in C++, but it would be awkward to ask the user to provide a hash function in the reference implementation (i.e., the one using list of pairs), but not use it anywhere :) In contrast, if we use the red-black tree implementation we would have to ask the user to provide a total order. It is overkill for the list of pair reference implementation because we just need an equality test, but, at least, the comparison function will be used in the implementation. 3- Add types `d_parray` (dependent persistent array) and `parray` (persistent array). In Lean, they would just wrap the `d_array` and `array` types. In the VM, `d_array` and `array` would be implemented using vanilla arrays and `d_parray` and `parray` would be implemented using persistent arrays. Then, we could have `d_hash_map`, `hash_map`, `d_phash_map` and `phash_map`. Argh, so many versions :( We would use `phash_map` to implement our reader and macro expander. 4- Add a `(persistent : bool := ff)` parameter to `d_array` and `array` types. The disadvantage of this approach is that it has a performance impact. The VM implementation would have to check the `persisent` flag at runtime. The value of this flag is known at compilation time, but we currently don't have a mechanism for specializing native builtin C++ implementations for VM functions.
10 lines
253 B
Text
10 lines
253 B
Text
run_cmd tactic.run_async (tactic.trace
|
||
"trace message from a different task")
|
||
|
||
def {u} foo {α : Type u} {n : ℕ} : array (0+n) α → array n α :=
|
||
if n = 0 then
|
||
λ v, cast (by async { simp }) v
|
||
else
|
||
λ v, cast (by async { simp }) v
|
||
|
||
#print foo
|