Arduino-copilot makes it easy to use Haskell to program an Arduino

Is this a thing now? Are we saying "codes" instead of "code"?

The short answer is that I could guess what it means.

This `arduino-copilot` example really showcases one killer application of Haskell: writing eDSL (embedded domain-specific language) in Haskell.

Haskell allows really high level abstraction: in particular, you can overload the operator which combines different statements in Haskell. In C/C++, the semicolon combines subsequent statements, Haskell even allows you to overload (give a new meaning to) the semicolon “operator” (think of overloading ; instead of overloading +). That is, in Haskell we can interpret differently how to combine subsequent statements in different contexts (such as null-checking, exception handling, async/await style concurrency, looping, or procedural state passing, etc., see the example below).

However, when we “overload the semicolon operator”, we intuitively have some expectations:

1. We expect to be able to turn a value into a standalone statement (to inject a value as a single statement with that value, e.g., to turn the value “97” into the statement “97;”, and this operation is called return)

2. We expect to be able to use the result of a statement in the next statement as in

    str <- getLine;
    putStrLn str

When we package up (encapsulate) the above two operations (return and bind), we expect the two operations to play nicely with each other to satisfy some intuitive laws (e.g,. if you inject a value then use the value in a subsequent functional statement, it is the same as just calling the function on the value, so the return and bind cancels out, etc.). A mathematical formalization of this idea (the two operations with some intuitive laws) is named a monad, which happens to generalize many different computational contexts of combining statements such as null-checking, exception handling, async/await style concurrency, looping, or procedural state passing [1].

[1]: https://philipnilsson.github.io/Badness10k/posts/2017-05-07-...

The ability to reinterpret statement compositions is why Haskell is so great for embedding domain-specific languages (even procedural eDSL), as the arduino article shows, and this is why some people call Haskell the finest procedural language.

It will bring many high level features like type safety, immutability, runtime error free code and code that is easy to refactor, once the Haskell learning curve is climbed. I like Haskell for its brevity and pseudo code like syntax which really runs like Python with all the necessary safety.

Given Haskell share in the overall eco-system of languages, I don’t expect it to have any significant impact. But this little steps are necessary to move forward Haskell.

I think the biggest stumbling block Haskell need to overcome is to have good documentation like Python. I believe if instead of just features, language research Haskell community needs to put extraordinary efforts in documentation. In spite of Haskell being an old language more than 50% of packages on hackage do not have proper documentation and unless that do not go up to 90% or more Haskell won’t be able to be used effectively by programmers to solve computing problems. We all stands on giants of shoulders and for that to happen need documentation. I believe people underestimated the power of good documentation. It should be twice or thrice more efforts than the language feature development itself.

The key sentence:

> This whole example turns into just 63 lines of C code, which compiles to a 1248 byte binary, so there's plenty of room left for larger, more complex programs.

What the eDSL (embedded domain-specific language) offers is a higher level of abstraction: by using functional reactive programming, the programmer can reason about the code at a more intuitive level (instead of C, assembly, or machine code).

Usually people call this style of programming declarative instead of imperative: focusing on what to do instead of how to do it.

In a more interesting example in the article, we see right away that the LED is on when, and only when, the button is pressed or when it is “blinking”, with “a longer and longer” delay (with lower level details deferred to the counter function, or with the timing logic handled by the functional reactive programming framework—to appreciate the abstraction ability of FRP, try to imagine how to implement the same LED (which is on when pressed or with a longer and longer delay) in other procedural languages, likely different concerns will be interleaved).

When concerns are cleanly separated in Haskell, we understand what the code intends to do right away, making the code more maintainable. (And more fun to read and write!)

As a side bonus, Haskell has a strong and expressive type system, and a pervasive use of laziness to enable purity, allowing local equational reasoning (e.g., no need to worry about hidden mutable global state, so functions could be understood on their own, etc.), making the code even easier to reason about and to maintain then some other procedural languages (what you write is what you intuitively mean).

So I think the trade off is between developer productivity and performance (of the generated C code vs a handcrafted C code; very much like the trade off between a compiled machine code vs a handcrafted machine code).

Squeezing every drop out of microcontrollers likely includes much bit-banging. Once you've given up perfect instruction cycle counting, they're all high level languages!

So keeping an open mind is actually the key factor here.

    #include <stdint.h>
    #include <stdbool.h>
    #include <string.h>
    static bool s0[(2)] = {(false), (true)};
    static size_t s0_idx = (0);
    bool s0_gen(void) {
      return (s0)[s0_idx];
    }
    bool delay_guard(void) {
      return true;
    }
    int16_t delay_arg0(void) {
      return 100;
    }
    bool digitalWrite_guard(void) {
      return true;
    }
    int16_t digitalWrite_arg0(void) {
      return 13;
    }
    bool digitalWrite_arg1(void) {
      return (s0)[s0_idx];
    }
    void step(void) {
      if ((delay_guard)()) {
        (delay)(((delay_arg0)()));
      };
      if ((digitalWrite_guard)()) {
        (digitalWrite)(((digitalWrite_arg0)()), ((digitalWrite_arg1)()));
      };
      ((s0)[s0_idx]) = ((s0_gen)());
      (s0_idx) = ((++(s0_idx)) % (2));
    }
    void setup()
    {
      pinMode(13, OUTPUT);
    }
    void loop()
    {
      step();
    }