purescript VS Idris2

Assuming this is a PS knock, fwiw this went away a good bit ago: https://github.com/purescript/purescript/releases/tag/v0.14.2

PureScript is a Haskell-like language aimed at providing an alternative to TypeScript for statically typed programming in the JavaScript space. I highly recommend taking a look at PureScript for your compile-to-JavaScript needs outside of the use case we'll be talking about in this post.

Tons of them, but I am most interested in the following for various reasons:

PureScript[1] — been around a long time. Looks a lot like Haskell to me.

Derw[2] — Elm-like, interesting integration with Typescript

Amber[3] — smalltalk for js

Rescript[4] — its been awhile since i last looked at this project (during a catastrophic rebrand) so I'm not sure where this project is at, but it did seem very promising to me at one point.

[1]: https://www.purescript.org/

[2]: https://github.com/eeue56/derw

[3]: https://amber-lang.net/

[4]: https://rescript-lang.org/

Thinking about "tools" in a more general sense, there is Pandoc,¹ which is an end-user application, and PureScirpt,² a programming language.

¹ https://pandoc.org

² https://www.purescript.org

There's Purescript with two libraries implementing the Elm architecture, flame and elmish (on React). Purescript only targets JS, but that can be embedded in mobile and desktop apps.

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.

The Idris codebase is quite beautiful. Given some understanding of how it works underneath, I find that there’s a succinct clarity in everything.

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

is a known issue because both (+) and floating point literals are overloaded and there is no principled way of declaring that one defaulting mechanism should have priority over another one.

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.

I was a bit disappointed with linearity in QTT as I couldn't figured out how to create a safe API around a resizable array.

The example given in the paper is a LinArray (https://github.com/idris-lang/Idris2/blob/main/libs/contrib/...). Unfortunately, as the community discovered, a user can "leak" a non-linear binding outside of the `newArray` constructor (which is what attempts to enforce linearity for all bindings). With multiple unrestricted handles, a user can accidentally double-free for instance. (https://github.com/idris-lang/Idris2/issues/613)

The fundamental issue in this case is that linearity in QTT is a property of the parameter bindings and _not_ the type itself, meaning we can't easily express linearity as a _global_ property of the type.

On the other hand, only affecting the parameter bindings makes it really easy to use runtime-erased/comptime stuff without reimplementing a bunch of common types as runtime- and comptime-only versions.

ATS chooses the other path and makes linearity and runtime-erasure a part of the type (not without paying a hefty syntactic cost however).

Idris 2 looks promising... I suggest keep an eye on it https://github.com/idris-lang/Idris2