ChezScheme VS Idris2

This is an update on building Idris2 for `arm64` Apple silicon. My original guide was posted here a year ago: [Success building native Idris2 on an M1 Mac](https://www.reddit.com/r/Idris/comments/pc5lib/success\_building\_native\_idris2\_on\_an\_m1\_mac/) Some issues I encountered may get fixed, so these notes may best serve as guidance, as others work through this install in the future. I no longer have any Intel Apple machines in use. I am using MacOS Monterey 12.5.1, and a current homebrew installation that includes needed support such as gmp. I have successfully built idris2 on several M1 Mac minis, an M2 Macbook Air, and an M2 Ultra Mac Studio. These directions assume that you have read the install docs for Chez Scheme and Idris. ---- The official Cisco [Chez Scheme](https://github.com/cisco/ChezScheme) is still not `arm64` native. As before, one needs to install Racket's [fork](https://github.com/racket/ChezScheme/), which is `arm64` native and supports Idris2. Cloning the git repository and attempting to build, one encounters the error Source in "zuo" is missing; check out Git submodules using git submodule init git submodule update --depth 1 After these steps, the build is routine using the steps arch=tarm64osx ./configure --pb make ${arch}.bootquick ./configure --threads make sudo make install One can now confirm that `scheme` is `arm64` native using the command file $(which scheme) ---- The Idris 2 build was a delicate puzzle for me, harder than before. I got it to run by hand once, and then lost hours trying to recover what I did right by script. Here is a GitHub Gist for my install script: [Build script for Idris 2 on Apple silicon](https://gist.github.com/Syzygies/15cbaebd5d7a31630650b7a8436a8f1f) Here are the issues I encountered: Seven of the nine case statements involving ta6osx have had t `arm64`osx added, but not the remaining two. This threw me, as I imagined this had to be deliberate, and this was one of several problems that needed fixing. The bootstrap build creates a file `libidris2_support.dylib` but then can't find it later. One needs to attempt the bootstrap build twice, copying this file after the first attempt fails so that the second attempt will succeed. I copied this file everywhere needed, rather than to `/usr/local/lib` (homebrew doesn't like sharing a lane). The executable script itself can fail to find this `.dylib`, but the executable looks in the current working directory, so one could easily miss this during development. I also patch the executable so it changes into the executable's directory before calling it, where one of several identical copies of this `.dylib` can be found. `INSTALL.md` included the curious note **NOTE**: If you're running macOS on Apple Silicon (arm64) you may need to run "`arch -x86_64 make ...`" instead of `make` in the following steps. The correct way to read this is that the author isn't sure. In fact, following this instruction will create `libidris2_support.dylib` with the wrong architecture, as I verified with a matrix of experiments (this or not, edit last two case statements or not). What is the status of official Apple silicon support for Chez Scheme and Idris 2? Searching Cisco [Chez Scheme](https://github.com/cisco/ChezScheme) issues for `arm64` yields several open issues, including [Pull or Backport ARM64 Support from the Racket Backend Version #545](https://github.com/cisco/ChezScheme/issues/545) proposing to pull the Racket fork support for Apple Silicon. Searching pull requests for `arm64` yields [Apple Silicon support #607](https://github.com/cisco/ChezScheme/pull/607), which doesn't work. The author doesn't explain why they are making this effort, rather than pulling the Racket fork changes. Others note that the author also ignores prior art in their naming conventions. Searching [Idris 2](https://github.com/idris-lang/Idris2) issues for `arm64` yields [Racket cannot find libidris2_support on Mac M1 #1032](https://github.com/idris-lang/Idris2/issues/1032), noting the `.dylib` issue I address, and linking to [Clarify installation instructions on macOS (M1) #2233](https://github.com/idris-lang/Idris2/issues/2233) asking for better Apple silicon directions, which backlinks to my first [reddit post](https://www.reddit.com/r/Idris/comments/pc5lib/success\_building\_native\_idris2\_on\_an\_m1\_mac/). The other backlinks I could find are automated scrapes not of interest. There are no pull requests for `arm64`. I admire the Idris project and I want it to succeed. It needs macOS users. However, I'm unlikely to rely on Idris2 for my own work until parallelism is better supported. I'd love someone to change my mind if I'm misreading the situation.

The Racket fork of Chez Scheme runs natively on Apple ARM (AFAIK these changes have not yet been merged into the main branch of Chez Scheme)

https://github.com/racket/ChezScheme/

I succeeding in installing a native arm64 Idris2 on an M1 Mac. I wish that I had found clear directions all in one place. I would be happy to contribute such directions, after experts have commented on what I did. Where should these directions go? As of this writing, the official Chez Scheme is not arm64 native, but the Racket fork of Chez Scheme is arm64 native. I first installed Racket's Chez Scheme (9.5.5.5), which appears to support Idris2. https://github.com/racket/ChezScheme/ It is likely that a full Racket installation will also put this somewhere, but I could not find it. Chez Scheme uses idiosyncratic machine types, which take some sleuthing to find. Once one has a working scheme, `(machine-type)` evaluates to the machine type, but there is a chicken-and-egg problem here. At a command line, `arch` prints the machine architecture, `i386` or `arm64`. The Chez Scheme machine type for an `i386` Mac is `ta6osx`. The Chez Scheme machine type for an `arm64` M1 Mac is `tarm64osx`. The full build instructions for Chez Scheme on an M1 Mac become arch=tarm64osx ./configure --pb make ${arch}.bootquick ./configure --threads make sudo make install sudo chown $(whoami) ${arch}/petite.1 ${arch}/scheme.1 The final `chown` keeps this directory from interfering with synchronization software such as `unison`. The Makefile is a bit sloppy about cleaning up ownership, and leaves these files assigned to `root`. I found that `make clean` did not sufficiently restore the Chez Scheme build directory to be used on a different architecture, so my script unpacks the build directory from scratch. I probably missed the correct scorched earth incantation; I know without diving into code that starting with a virgin build directory works. Now, a bootstrap build of Idris2 requires two tweaks. https://www.idris-lang.org/pages/download.html First, the build needs `gmp` which I installed via Homebrew. However, Homebrew provides the file `/opt/homebrew/include/gmp.h` on an M1 Mac, rather than `/usr/local/include/gmp.h` as on other Macs. The build uses `/usr/bin/cc` which knows about `/usr/local/include` but not `/opt/homebrew/include`. One needs to set the `CPATH` environment variable. One therefore builds with the commands export CPATH="/opt/homebrew/include" make bootstrap SCHEME=scheme make install Apparently Homebrew had an `#M1too` moment where they were convinced that it was poor practice to use `/usr/local` because others do, so they switched to `/opt/homebrew` for M1 Macs. I never had a problem with this, but I don't relish having recurring problems separately teaching every language in my programming zoo how to find libraries provided by Homebrew. I wish I could find the tortuous discussion leading to this decision, for I'm sure it would be delightful reading, and might shed light on this. There is a final problem: The Idris2 build is unaware of the Racket Scheme machine type. As I start with virgin build directories for each machine, I found it simplest to globally replace every occurrence of `ta6osx` by `tarm64osx`. This works. One should perhaps add `arm64osx` and `tarm64osx` to the existing code, alongside `ta6osx`. I don't fully understand the naming conventions (one wants to guess in advance what the official Chez Scheme will choose when it supports M1 Macs), or the code I was modifying, so I didn't test this.

Have you looked into Idris2 at all. While looking into these theorum provers, it always felt like they had an impedance mismatch with normal programming.

Idris2 portends to a general purpose language that also has a more advanced type system for the theorum proving.

https://github.com/idris-lang/Idris2

The original paper also does plain STLC first in section 2, and then adds dependent types in section 3. (And finally it adds the naturals in section 4.)

In the Idris2 github repository, Guillaume Allais goes a step further and shows a well-named version. There the types of terms and values are indexed by the list of names in the environment and the compiler checks that the manipulation of deBruin levels and indices is correct:

https://github.com/idris-lang/Idris2/blob/main/libs/papers/L...

Most of the proof assistants out there: Lean, Coq, Dafny, Isabelle, F*, Idris 2, and Agda. And the main concepts are dependent types, Homotopy Type Theory AKA HoTT, and Category Theory. Warning: HoTT and Category Theory are really dense, you're going to really need to research them.

Here's the full tab list: - https://tjpalmer.github.io/languish/ - https://blog.python.org/2022/10/python-3110-is-now-available.html - https://devblogs.microsoft.com/python/python-311-faster-cpython-team/ - https://github.com/tc39/proposals/blob/main/finished-proposals.md - https://devblogs.microsoft.com/typescript/ten-years-of-typescript/ - https://devblogs.microsoft.com/typescript/announcing-typescript-4-6/#cfa-destructured-discriminated-unions - https://devblogs.microsoft.com/typescript/announcing-typescript-4-9/#the-satisfies-operator - https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/#go-to-source-definition - https://devblogs.microsoft.com/typescript/announcing-typescript-4-8/#build-watch-incremental-improvements - https://openjdk.org/projects/jdk/18/ - https://openjdk.org/projects/jdk/19/ - https://blog.jetbrains.com/clion/2022/07/july-2022-iso-cpp/ - https://en.wikipedia.org/wiki/C%2B%2B23 - https://en.cppreference.com/w/cpp/23 - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2128r6.pdf - https://devblogs.microsoft.com/dotnet/announcing-dotnet-7/ - https://devblogs.microsoft.com/dotnet/welcome-to-csharp-11/ - https://devblogs.microsoft.com/dotnet/announcing-fsharp-7/ - https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ - https://go.dev/blog/go1.19 - https://go.dev/blog/go1.18 - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu#n3017---embed - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu#n3006--n3007---type-inference-for-object-definitions - https://www.php.net/archive/2022.php#2022-12-08-1 - https://wiki.php.net/rfc/dnf_types - https://blog.rust-lang.org/ - https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html#captured-identifiers-in-format-strings - https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html#inline-assembly - https://blog.rust-lang.org/2022/05/19/Rust-1.61.0.html#more-capabilities-for-const-fn - https://blog.rust-lang.org/2022/08/11/Rust-1.63.0.html#scoped-threads - https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#generic-associated-types-gats - https://blog.jetbrains.com/kotlin/2022/06/kotlin-1-7-0-released/ - https://stat.ethz.ch/pipermail/r-announce/2022/000683.html - https://dart.dev/guides/whats-new - https://medium.com/dartlang/dart-2-18-f4b3101f146c - https://medium.com/dartlang/the-road-to-dart-3-afdd580fbefa - https://www.swift.org/blog/swift-5.6-released/ - https://www.swift.org/blog/swift-5.7-released/ - https://www.swift.org/blog/swift-language-updates-from-wwdc22/ - https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/ - https://www.lua.org/news.html - https://www.scala-lang.org/blog/2022/09/05/scala-3.2.0-released.html - https://tjpalmer.github.io/languish/#y=mean&weights=issues%3D1%26pulls%3D0%26stars%3D1%26soQuestions%3D1&names=solidity%2Chaskell%2Cjulia%2Celixir%2Cclojure%2Cperl%2Cgroovy%2Cocaml%2Cgdscript%2Ccmake%2Cnix%2Cvisual+basic+.net - https://blog.soliditylang.org/ - https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html - https://julialang.org/blog/2022/08/julia-1.8-highlights/ - https://discourse.julialang.org/t/julia-v1-9-0-beta2-is-fast/92290 - https://elixir-lang.org/blog/2022/09/01/elixir-v1-14-0-released/ - https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ - https://clojure.org/news/2022/03/22/clojure-1-11-0 - https://godotengine.org/en/news/default/1 - https://ocaml.org/news/ocaml-5.0 - https://tjpalmer.github.io/languish/#y=mean&weights=issues%3D1%26pulls%3D0%26stars%3D1%26soQuestions%3D1&names=gdscript%2Czig%2Cpascal%2Cfortran%2Cnim%2Cf%23%2Ccommon+lisp%2Cwebassembly%2Ccrystal%2Ccython%2Cvala%2Cerlang%2Chaxe%2Cv%2Cd - https://ziglang.org/download/0.10.0/release-notes.html - https://ziglang.org/news/goodbye-cpp/ - https://nim-lang.org/blog.html - https://nim-lang.org/blog/2022/12/21/version-20-rc.html - https://www.erlang.org/news/157 - https://github.com/WebAssembly/proposals/commits/main - https://github.com/crystal-lang/crystal/releases - https://dlang.org/changelog/2.099.0.html - https://dlang.org/changelog/2.100.0.html - https://dlang.org/changelog/2.101.0.html - https://github.com/odin-lang/Odin/releases - https://gleam.run/news/ - https://gleam.run/news/gleam-v0.22-released/ - https://gleam.run/news/gleam-v0.24-released/ - https://github.com/idris-lang/Idris2/blob/102d7ebc18a9e881021ed4b05186cccda5274cbe/CHANGELOG.md - https://github.com/diku-dk/futhark/blob/master/CHANGELOG.md#02111 - https://grain-lang.org/blog/2022/06/06/new-release-grain-v0.5-durum/ - https://rescript-lang.org/blog/release-10-0-0 - https://www.roc-lang.org/ - https://simon.peytonjones.org/assets/pdfs/haskell-exchange-22.pdf - https://vale.dev/ - https://www.val-lang.dev/

Idris2 has a great syntax for this, see e.g. node018:

I asked because it just baffles me any time I see a dependently typed language using unary numbers. I think to myself, "are these people even educated? Do they know about number systems?" I mean, cavemen were the last group using unary number system as their mainstay, and that was during the Paleolithic. Then they have issues open like this when they discuss optimizing those damn unaries. But this shouldn't even have been a problem for anyone even remotely related to programming! It's giving a terrible impression of dependently-typed languages. Getting rid of those should be the first step of popularizing them.

addOne : Int -> EitherT String IO Int addOne x = pure $ x + 1 add : Int -> Int -> EitherT String IO Int add x y = pure $ x + y main : IO () main = do exportFn `{add} the (IO ()) $ exportFn `{addOne} -- `the (IO ())` is needed due to issue https://github.com/idris-lang/Idris2/issues/2851

The idea of world state is an attraction of the state that side effects change. I got the idea from Idris internals: https://github.com/idris-lang/Idris2/blob/main/libs/prelude/PrimIO.idr