It is still broken since we apply attributes before we compile code.
Recall that attributes such as `@[export]` and `@[extern]` must be applied before we
compile code.
On the other hand, any attribute `attrName`
```
@[attrName] def foo := ...
```
which creates auxiliary definitions that depend on `foo` must be applied
AFTER we generate code for `foo`. Otherwise, we will fail to compile the
auxiliary definition since we don't have code for `foo` yet.
I will fix the issue above by allowing attributes to specify when they
should be applied. I will start with only two options: before and after
code compilation. In the future, we may need more options (e.g., before
elaboration), but I don't see the need yet.
cc @kha
@kha The previous declaration was fine from the logical point of
view. That is, nobody would be able to prove `false` using the opaque
constant `unsafeIO`. However, its runtime implementation breaks
referencial transparency, and counterintuitive behavior may happen if
it is not used carefully.
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.
