
Interesting! It's been awhile since I've worked on FPGAs :) ATS is the only language I've seen that advertises stack-allocated closures, and I think GHC's approach to laziness requires heap allocation, so there's still a few targets (AVR off the top of my head) that GHC would need significant modification to work on. On 10/20/18 9:52 PM, Will Yager wrote:
On Oct 20, 2018, at 09:11, Vanessa McHale
wrote: I would hesitate to use Haskell in the embedded context or for hardware-level stuff. I presume GHC's approach to laziness has a role in this. There’s a bit of a complication here. It’s true that standard GHC generated code is unsuitable for hard-real-time/embedded environments (although I would argue that it’s actually fine for general purpose OS programming). However, as far as hardware goes, the semantics of (a non-monomorphically-recursive subset of) Haskell is actually a surprisingly close match for the semantics of hardware (as in LUTs and flip-flops, not as in random microcontrollers). This is the basis of projects like Clash (Haskell to HDLs). I imagine one could extend the clash approach to generate allocation-free assembly from the same (large) subset of Haskell.
I don't have much experience with OCaml but my experience with ATS is that it's very much possible to have functional, ML-style programming without a runtime or even dynamic memory allocation. It’s possible to write low-allocation (I wouldn’t call it “allocation free” - usually just the hot loops don’t allocate) OCaml with the standard tools. However, it requires a fairly non-idiomatic style.
—Will