In the Haskell proposal for top level mutable state
https://wiki.haskell.org/Top_level_mutable_state, they describe the
following problems with using the `IO` monad during initialization.
"A more serious problem is that there is nothing to prevent arbitrary
observable IO actions from appearing to the right of the arrow. If we
perform all actions before executing main, then import becomes a
side-effectful operation, rather than simply a way of bringing names
into scope; furthermore we must specify the order in which actions from
different modules are executed, which would appear to be difficult in
general. If we execute actions on demand (as the unsafePerformIO hack
does) then we are building an unsafe syntactic construct into the
language."
I believe this is not applicable to us. First, our imports are already
side-effectful since we update attributes and the order we import
modules already matters. Second, we have already a well-defined order
in which we import modules. Finally, all global constants are already
being initialized eagerly.
Their ACIO proposal (`init_io` in our implementation) is too restrictive
for what we want to do. For example, to implement an environment
extension mechanism like we have discussed, we would also need `io.ref.write` and
`io.ref.read`. I imagine, we would have a global table, and `register`
would update this table. These extra actions do not satisfy the ACIO restrictions
described in the Haskell proposal. From their document:
"AC stands for Affine Central.
An IO action u is affine if its effect is not indirectly observable, hence need not be performed if the result is unneeded. That is, if u >> v === v for all actions v.
It is central if its effect commutes with every other IO action. That is, if do { x <- u; y <- v; w } === do { y <- v; x <- u; w } for all actions v and w."
It feels like we would have to keep fighting with the ACIO
restrictions. As I said above, our initialization order is well
defined. So, we must document the `[init]` feature and tell users they
should be aware that the `import` is important for initialization
purposes, and that their initialization actions should be
affine central whenever possible.
Remark: `vm_timeit` was for the Lean 3 `timeit` primitive which is
different from the Lean 4 one. It has a different arity, and was
producing an assertion violation at emit_bytecode.cpp
@kha I found yet another bug in the specializer code :(
The bug is related to the previous bug fix where we try avoid
duplication of work by lambda abstracting let-variables.
We knew this could introduce type errors, but I thought it would only
happen in very complicated programs that make a heavy use of dependent
types. Actually, this is not the case. I just found an instance when
I was playing with the new parser.
The idea is to avoid allocating tuples when creating the fixpoint of
nary functions. For example, consider the new tests:
- tests/playground/fix.lean
- tests/playground/fix_with_tuples.lean
The second one (`fix_with_tuples`) uses the `fix` operator and tuples. For input = 20,
it creates more than 1 million extra objects. The first implementation
(`fix.lean`) using `fix₂` avoids this overhead.
TODO: Add support for pattern #N with N > 9 at
```
def expand_extern_pattern_aux (args : list string) : nat → string.iterator → string → string
```
