Are there any special challenges for functional programming in an embedded environment?

So I'm starting to get a feel for what sets functional programming apart from imperative programming. So like any good convert I'm looking at things with the Haskell hammer and trying to imagine how my embedded programming work could be shaped as appropriate nails for that tool.

So that got me thinking about this question. Is the embedded environment a special case of general computing in the eyes of functional programming or is it just another form of the general case? Is the challenge all in the IO? My embedded work usually entails about 90 - 95% peripheral IO work and the last little bit of stuff being what algorithm work I can fit onto it and still make it back to my IO in time. Does that sort of work make a functional program unsuited to my needs?

开发者_如何学编程

Finally, if there are any projects to embedded Haskell projects you could suggest, that'd be greatly appreciated. Thanks.

---

There are a number of promising projects for bringing functional programming to the embedded programming world.

It seems like a common approach is to take advantage of the type safety and other correctness features of but to abandon heavyweight runtime like ghc. As a result of abandoning the run time, you give up features like garbage collection. Instead, embedded Haskell projects use embedded DSL languages that output real time C code.

Embedded projects using mix C, C++ and Haskell code, rather than being pure functional projects. The C code produced from the Haskell code is not idiomatic C code so collaborators on the project typically need to be familiar with Haskell syntax to participate.

Galois's Copilot project is one the mode extensively documented embedded Haskell projects.

http://corp.galois.com/blog/2010/9/22/copilot-a-dsl-for-monitoring-embedded-systems.html

Copilot uses the Atom DSL which seems popular

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/atom-0.0.2

There is also a moderately active Google Group

https://groups.google.com/forum/#forum/fp-embedded

---

Personally I found Haskell.Atom quite lacking. It's not functional programming it's an EDSL in a functional language. You are limited to the constructs of that EDSL. No higher order functions, list comprehensions and all the other things that make functional programming so succinct and enjoyable. It may be fun for exceptionally small projects (like blinking a LED) but to me it seems the code you write (not only the generated C-code) will grow exponentially compared to the functionality it provides.

If you want to go the functional route I suggest reading this paper by Malcolm Wallace. It's a bit dated but at least it describes in quite a detail how to do low-level I/O, IRQ-handling and so on in a pure functional language (Gofer, a Haskell-dialect).

Update: There's also a quite new research project with the goal to make a functional systems programming language based on Haskell, Habit. Unfortunately it seems to exist mostly in theory.