Lambda the Ultimate

Wasn't this in Koen Claessen's PhD thesis? I remember liking the approach but to go industrial this actually, sigh, is one example where I would implement it in ocaml (better performance, eager thus predictable, and yeah well, impure). I also remember not really liking the block structured approach for circuit design - felt it would be way to cumbersome to actually use industrially.

My own shot-out-of-the-hip approach would be to implement some language on top of some hardware combinator library in ocaml and to translate to VHDL or SystemC. What's wrong with SystemC for your project anyway?

For what it's worth, your language seems simple enough to easily translate to any HDL, even if implemented in C++.

Wasn't this in Koen Claessen's PhD thesis?

I designed Lava primaraily for efficient and compact implementation of structural circuit descriptions onto Xilinx FPGAs. So if you want to have a lot of control over layout and/or you want to have interfaces to SAT-solvers etc. then there might be some benefit in using Lava (and I am willing to update it to newer devices if there is any interest). However, if you want something higher level which can be subjected to synthesis etc. then you will find Lava is proably at the wrong level of abstraction.

Well, you might take a look at Strafunski. It's a Haskell package for generic traversal. Quoting from their website:

Strafunski provides programming support for generic traversal as useful for the implementation of program analyses and transformation components of language processors. Strafunski is based on the notion of a functional strategy. These are generic functions that can traverse into terms of any type while mixing type-specific and uniform behaviour.

Rather than everyone just trotting out their favourite tools?

Ok, I'll try. First up, modularity: OO makes it very easy to extend a data type: you just create a new subclass. However adding a new method requires you to alter every class in the hierarchy. FP is the exact opposite. Adding a new function to a datatype is easy, but extending a datatype requires you to modify every existing function. So FP is more appropriate if you think you'll be creating more new functions than datatypes, and from your problem description I think you will be. BTW, generic functions are a middle ground that solve this modularity dilemma, but introduce a bunch of new issues.

Now let's look at expressing tree traversals and transforms. I find the Visitor pattern in OO very convoluted. In comparison FP lends itself naturally to expressing transformations of recursive data structure (i.e. trees). Pattern matching is a great advantage here, and every FP language has some form of pattern matching. The use of higher-order functions also allows you to concisely express common traversal patterns and then parameterise the traversals by the types of transforms you want to perform. Generic traversals are known as folds in the literature, and I suggest looking at Oleg Kiselyov's foldts for a generic tree fold.

Summary: manipulating trees is one of the strengths of FP.