@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.
A C++ vtable at `external_object` is bad because it prevents users
from implementing external object in different programming languages.
Another problem was memory leaks because of the vtable in the
beginning of the object.
cc @kha
@kha I have disabled this check. It was implemented 2 years ago by
Daniel, and I don't want to fix it. It seems you have already fixed a
bug there. AFAICT, this check is just for improving error messages.
I believe we may not even need it since the kernel now supports nested
inductive types. AFAIR, Daniel implemented this check here because the
inductive compiler was introducing a lot of auxiliary declarations
that were making the kernel error messages unreadable.
We cannot check the `[extern]` attribute because the auxiliary
declarations are compiled before we even define the main declaration
and set the attribute.
We should consider a better design in the future where we first define
all auxiliary and main definitions, then set the attributes, and then
compile the code.
cc @kha
@kha, it was a `class parser` vs `struct parser`.
I just fixed the warning by using `struct parser` everywhere.
It is ugly, but we will eventually delete the old parser.
In
```
section binary
variables {α : Type u} {β : Type v}
variable f : α → α → α
local infix * := f
def commutative := ∀ a b, a * b = b * a
end binary
```
the expansion of `*` applies a macro scope to `f`, so we need to resolve it
before that
