How to do functional programming efficiently in C?

Don't.

It won't be as elegant as in a language that's expressly made for it, but it's fairly easy to throw functions as arguments to other functions via function pointers.

You can also implement a clunky kind of algebraic datatype using tagged unions (union with an accompanying flag variable that tells you what kind of value is in the union) for the sum type and structs for the product type.

Closures/lambdas are not trivial to implement, you could try ensuring that every function takes an environment structure along with it or as an argument.

Please use something actually intended for it.

@metamourge does it means we have to do imperative programming when it comes to system level?

@PrivateGER how about using functional philosophy in C?

@RememberMe I'm planning to use functional approach as much as possible, without adding much complexity, will try to use your advice as well.

@irene well I'm trying more of functional style then pure functional... Well thanks for your advice..🤘

@boywigh if you're looking for a fast systems language which is based on functional programming then I would recommend you learn OCaml.

While it does have a few language design warts it doesn't have any of the scary category theory based background of Haskell etc. (No need to worry about monads for the most part) and has strict evaluation so it's really easy to figure out what it's doing.

OCaml is used for some pretty low level stuff for a functional language, check out MirageOS.

@RememberMe will definitely look into it... Thanks for advice 🤘

@boywigh C is sort-of a 'higher-level assembler', and system programming has a lot to do with doing I/O, moving memory around, and similar things that don't lend themselves well to functional programming.

This is not to say that functional programming has no place at all in system programming, even in C you can use concepts like pure functions and avoiding mutable state, where appropriate.

@SomeNone that's a good thought, planning to start with that in next project...

@RememberMe definitely, sounds interesting...😊

Why would you even want functional style in systems programming? That's not the place to get fancy-shmancy with abstractions. It's the very basis, and the whole mindset of not wanting to deal with the hardware is unsuited for system level programming.

Also, it's bad case for FP because FP sucks with state, which you need at that level all around, and at behaviour, which is the point of that layer.

You can use function pointers in C, e.g. for callbacks, but that should be used sparingly both because of performance and maintainability.

@Fast-Nop agreed or may be we can design pure function at system level with Unix philosophy. May be it will simplify the system design process and multicore efficiency...

@boywigh Unix philosophy applied yields something like the Linux kernel, which is why Torvalds has never wanted people who can't deal with hardware on raw byte level.

Pure function doesn't make sense because you're not implementing math calculations, you're implementing behaviour.

@Fast-Nop there's nothing wrong with pure functions, they're pretty much always a good thing and trying to make your functions pure doesn't mean you need to have huge towers of abstraction or that you can't deal with raw hardware stuff.

Also using pure functions doesn't mean you have to enforce purity throughout your system. The whole idea is to keep side effects controlled and demarcated, not sprinkled everywhere throughout the code base.

Also, impure functional programming is a thing as well, and quite suited for systems stuff. Not all FP is about building abstraction, sometimes all we do is do pretty much same thing as we would in C but leverage the FP language's much more powerful and expressive type system.

@RememberMe As soon as you have to deal with OS level stuff like memory barriers, alignment, cache lines, CPU config registers, pipelining, even down to steady electrical levels etc., all of that just goes out of the window. It's real, dirty hardware, the stuff that many CS guys are horribly afraid of exactly because it's no longer nice abstract math.

Sure, if you have something to calculate from some parameters, making it a pure function is nice. It's just that this isn't really often at that level.

@Fast-Nop I think we're talking about different stuff here. OP wanted to know how to use FP concepts in C. The direct-to-hardware systems programming you're talking about is just one area of systems stuff and is just one thing that C is used for.

I'm talking about using FP languages and/or FP-influenced C to implement things like fast DSP algorithms for a sensor driver, which is totally a valid use case, sensitive to hardware details, and has tons of places where you can stick pure functions.

@RememberMe Yeah with signal processing, that may be. Though e.g. implemention of stuff like IIR filters in FP would seem to be awkward given that you have to work around the filter state while it's straight forward in procedural or OOP.

But OK, working around the language paradigma seems often part of the fun for FP fans anyway.

Step 1 : Change language
Step 2 : Profit