I think purity is something the programmer just has to annotate themselves. Any boundary between languages with different type system guarantees will always have this kind of friction - Rust to C/C++ FFI also has to deal with ownership, lifetimes and aliasing manually.

Regarding type classes, monomorphisation indeed seems like a difficult obstacle for polymorphic function. But just translating type classes and impls might not be as difficult? So going from:

    trait Foo {
      fn foo(&self);
    }
    
    impl Foo for Bar {
      fn foo(&self) {...}
    }

    class Foo a where
      foo :: a -> IO ()
    
    instance Foo Bar where
      foo :: Bar -> IO ()
      foo self = ...

Some questions/ideas:

- Is there a way to generate #[hsrs::data_type] bindings for Rust library types, or do you need to create custom wrapper types for them?

- It seems like all #[hsrs::function]s are translated to return IO (since Rust functions can do arbitrary side effects). It would be great if you could (unsafely) mark functions as pure, to get pure Haskell functions without having to wrap them in unsafePerformIO.

- Both Haskell and Rust have HM type systems, so I wonder if you could also translate type classes from Rust to Haskell.

In theory, braking distance scales quadratically with speed. In practice, people leave less room on highways, because they rely on others driving predictably, but spacing still increases faster than linear.

- Imperfect information, aka Market for Lemons: It can be hard to find out how prevalent ads will be when buying a product. Consumers often make a purchasing decision without knowledge about ads.

- Changing terms after lock-in, aka Enshittification: Manufacturers (like Hisense here) can add advertising to products after consumers have already bought them. Initially, consumers have negotiation power since they can freely choose a product, but later they are locked in and cannot easily react to the manufacturer changing the product to their detriment.

> By doing so, we aim to provide a novel paradigm [...]

also made me think of item 19 on your list:

> 10 points for claiming that your work is on the cutting edge of a "paradigm shift".

I'm sad though that you didn't call it the "Baez crackpot index"...

https://en.wikipedia.org/wiki/Cyclorotor

Reminds me of the '$' operator in Haskell - it lowers the precedence of function application, basically being an opening parenthesis that's implicitly closed at the end of the line.