@Kha
I was having several errors of the form
```
224: /Users/leonardodemoura/projects/lean4/build/release/stage0.5/bin/../include/lean/runtime/exception.h:23:13: error: exception specification of overriding function is more lax than base version
224: virtual ~throwable() noexcept;
224: ^
224: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/exception:102:13: note: overridden virtual function is here
224: virtual ~exception() _NOEXCEPT;
224: ^
224: In file included from myfuns.cpp:1:
```
As far as I can tell, the error ocurrs because my compiler uses an old
C++ standard if the option `-std` is not used.
I guess `-std=c++11` would also works, but I decided to use the same
standard we used to compile Lean.
Since we don't use static initializers, really the only difference between using `clang` and `clang++` is the default
inclusion of the C++ standard library.
@Kha I tried to fix a few issues with private names. The new test
tries to cover them. If you have more, please create an issue.
1- Scoping. A private declaration should shadow one in a previous scope.
2- We should not be able to define the same `private` in the same
module more than once.
```
private def x := 10
private def x := "hello" -- should produce error here
```
3- Dot-notation should work with private declarations in the module
where they were defined.
4- The following should work
```
namespace N
private def x := 10
end N
#check N.x
```
5- The following should **not** work
```
def y := 10
private def y := "hello" -- produce error
private def z := 10
def z := "hello" -- produce error
```
BTW, I am happy to change this behavior. I just mimicked C's
behavior for `static`.
It is not clear whether the following should work or not.
```
namespace N
private def b := 10
end N
open N
#check b
```
@dselsam @kha
I did not have to create a new shared library.
The main limitation of this approach is that the new `extern`
functions are only available in compile code. That is, we cannot use
them with `#eval`.
We cannot implement `DecidableEq Float` using C equality for
`double`. Reason: the C implementation is not even reflexive.
If we need `DecidableEq Float`, we will need to provide our own
implementation (i.e., a wrapper around the one provided by the
hardware). In this commit, we implement `HasBeq Float` instead.
cc @dselsam
