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.
@kha I have added support for opaque constants to the old C++ frontend,
and made sure the new frontend can still parse `library/init/core.lean`.
The kernel should enforce that opaque constants are really opaque, and
the following example should fail
```
constant x : nat := 0
theorem foo : x = 0 := rfl
```
If it doesn't, it is a bug.
Here are some remaining issues:
1- `environment.mk_empty` is currently an axiom because we cannot create
an inhabitant of an opaque type. A possible solution is to use
`option environment` instead of `environment`.
2- There is no support for opaque constants in the new
frontend. However, I modified it to handle axioms, and fixed the literal
values with decl_cmd_kind. I tried to mark some of my changes with
comments, but it is probably much easier for you to just check the
commit change list.
3- I did not add any support for automatically constructing `e`
at `constant x : t := e`. I think we can do this later
after we replace the old frontend with the new one. BTW, it took only a
few minutes to provide the inhabitants manually.
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
```
