Extremely Eager, Eager, and Lazy Programming Languages

Most hardware description languages in a sense are extremely eager. The logic described always runs. Most programming languages are lazy, functions described only run when called. Haskell is extremely lazy in that sense.

Bluespec is somewhere in between lazy and extremely eager. Functions/rules always run - but only when they legally can run. Functions/rules in bluespec will only run if they can run atomically, which is a necessary condition for concurrency safety in the broader context of programming languages.

Merging Hardware and Software

There have been many attempts to compile C to hardware, but this field has never really taken off because in addition to C being too permissive with respect to its type system, C fails to encode concurrency semantics.

Bluespec on the other hand explicity enforces safe concurrency behaviors and has a strong and safe algebraic data type system.

With a few tweaks to the bluespec frontend, I truly believe it should be possible to describe general purpose software in bluespec, and with a major overhaul to the bluespec backend, I think it should be possible to add multicore systems as a compiler target for bluespec, in addition to the already existing verilog backend for bluespec.

I know Clash-haskell can already do this to an extent, but my exposure to Clash leads me to conclude that Clash makes this process rather difficult. Also, clash does not enforce concurrency safety at the compiler level the way bluespec does.

As a drawback however, the SMT solver used to prove concurrency safety in bluespec can sometimes take a while to finished before bluespec code will pass the concurrency safety check phase of compilation.

This is somewhat analogous to the Rust compiler's borrow checker being slow at times.

Condition Needed for Concurrency Safety

As far as I've been able to surmise, atomic updates to state will ensure concurrency safety, although in practice, not all updates have to be atomic if some state is local.

From a compiler's perspective, atomic operators make it easier to reason about atomic updates to state.

Lastly, depending on the programming paradigm, it may be necessary to have a particular function in a program block on a shared resource that must be atomically updated.

Bluespec satisfies all these requirements.

Differentiable Programming

In theory, it is possible to compute the gradient of the output of a program with respect to the program's inputs in purely functional languages such as haskell - making certain classes of programs inherently optimizable in nature.

PyTorch and TF are obviously differentiable programming framework - but they are not really considered general purpose. There is currently some interest in investigating how to construct a general purpose differentiable programming language.

I'd like to see how this area evolves, and in particular, I'd like to
understand the mechanisms needed to differentiate a function that has recursion.