ada-spark-rfcs VS HVM

Original discussion was there, I guess you can post your comments to that PR to keep the discussion in one place.

I forgot where I saw it, but I do recall reading somewhere that the ARG had discussed whether a shorter revision cycle would be better or not. I wouldn't be surprised if the creation of this ( https://github.com/AdaCore/ada-spark-rfcs ) was inspired by that discussion.

Ada might be getting pattern matching soon too:

https://github.com/AdaCore/ada-spark-rfcs/blob/master/protot...

> I did some ADA in the past and yes, it is a nice language, but it lacks the modernity and a dynamic community like Rust. ADA did received some nice update to its specification, but, just like C++, it struggle / cannot really fit the latest innovation in programming language that easily.

I'm still learning both Ada and Rust, nevertheless I humbly disagree. The more I learn it and other "old" languages the more it looks to me like "modern" ones rediscover things that have been present in other languages for years.

The really significant difference I can see for now is that Ada is not focused so strongly on functional programming paradigm. Rust borrow checker is a strong success of course and was another significant difference, but latest SPARK got borrow checking capabilities too, AFAIK.

While Ada's open-source community is smaller, I find it as energetic and devoted to improving the ecosystem as Rust's. I have no idea about closed-source community, but in the past 4 years ArianeGroup [1], Airbus [2] and Nvidia [3] talked about choosing Ada for their high-integrity applications.

> And to be fair, it is fine. ADA is very much a "committee" language (its spec are ISO/IEC) instead of a "community" language (all the spec and rfc of Rust are on github and anyone can easily discuss them).

You can discuss Ada/SPARK RFCs here: https://github.com/AdaCore/ada-spark-rfcs . I think I once saw on Ada forum or chat that someone proposing changes to the language was simply invited to talk to people working on the standard, so it doesn't look like the language is developed in isolation or something.

> This makes it so that ADA doesn't get the attention, and the rapidity of innovation, that a language like Rust does, but ADA is mostly made for program that will need to be maintained in critical operations for decades with the code being maintainable and compilable far into the future.

I think that Ada adopted quiet quickly to standards set by Rust: lower entry barrier toolchain, compelling licensing, library distribution, RFCs, etc. And in terms of language features, in many areas it's not only on par, but ahead of competition. So you're less likely to see lots of changes, but they do happen nevertheless. I'm not saying Ada is perfect, of course. There are parts of it that other languages do better. No shame in that.

IMHO, the reason Ada is unknown to many people is a combination of its past, myths surrounding it, and general trend of people to follow trends. ;) But I currently find Ada/SPARK even more compelling option than Rust, even though I like both.

[1] https://www.facebook.com/ArianeGroup/posts/2872955946126067

There's a proposal to allow dot syntax for untagged types as well.

There's also an active discussion about adding format strings to the language here: https://github.com/AdaCore/ada-spark-rfcs/pull/77

Reminds me of HVM[0]

[0]https://github.com/HigherOrderCO/HVM

Really interesting to see how new lang concepts and refinements keep popping up this last decade, between Vale, Gleam, Hylo, Austral...

Linear types really opened up lots of ways to improve memory management and compilation improvements.

I have a tangential question that is related to this cool new feature.

Warning: the question I ask comes from a part of my brain that is currently melted due to heavy thinking.

Context: I write a fair amount of Clojure, and in Lisps the code itself is a tree. Just like this F# parallel graph type-checker. In Lisps, one would use Macros to perform compile-time computation to accomplish something like this, I think.

More context: Idris2 allows for first class type-driven development, where the types are passed around and used to formally specify program behavior, even down to the value of a particular definition.

Given that this F# feature enables parallel analysis, wouldn't it make sense to do all of our development in a Lisp-like Trie structure where the types are simply part of the program itself, like in Idris2?

Also related, is this similar to how HVM works with their "Interaction nets"?

https://github.com/HigherOrderCO/HVM

https://www.idris-lang.org/

https://clojure.org/

I'm afraid I don't even understand what the difference between code, data, and types are anymore... it used to make sense, but these new languages have dissolved those boundaries in my mind, and I am not sure how to build it back up again.

Impressive presentation but I find two things missing in particular:

* GRIN [1] - arguably a breakthrough in FP compilation; there are several implementation based on this

* HVM [2] - parallel optimal reduction. The results are very impressive.

[1] https://link.springer.com/chapter/10.1007/3-540-63237-9_19

[2] https://github.com/HigherOrderCO/HVM

Purity has nothing to do with memoization. Haskell's semantics never "rewrite under a lambda" (unlike, e.g. HVM). Calling (\_ -> e) () twice will (modulo optimizations) always perform the computation in e twice.

The most recent exploration of this, that I'm aware of is HVM (another intermediate language / runtime), although this one is not actually based on the lambda calculus, but on the interaction calculus.

Then, actually unrelated but worth mentioning: HVM. Finally, something new on the functional front that isn't dependent types!

If you are into functional PL, how about https://github.com/HigherOrderCO/HVM? You could experiment if you could schedule that on a GPU?

In the interest of seeking ways of optimizing my code, I stumbled upon http://www.rntz.net/datafun/ as a means to do incremental computations of fixpoints while avoiding redundant work. And also the idea of automatic parallelism achieved by using Interaction Nets as a model of computation https://github.com/HigherOrderCO/HVM.