Decomposition (modularity) in functional languages

views:

answers:

+3 Q:

Decomposition (modularity) in functional languages

Got an idea: functions (in FP) could be composed similar was as components in OOP. For components in OOP we use interfaces. For functions we could use delegates. Goal is to achieve decomposition, modularity and interchangeability. We could employ dependency injection to make it easier.

I tried to find something about the topic. No luck. Probably because there are no functional programs big enough to need this ? While searching for enterprise scale applications written in FP I found this list. Functional Programming in the Real World and this paper. I hope I just missed the killer applications for FP, which would be big enough to deserve decomposition.

Question: Could you show decent real-world FP application (preferably opensource), which uses decomposition into modules ?

Bonus chatter: What is the usual pattern used ? What kind of functions are usually decomposed into separate module ? Are the implementations ever mocked for testing purpose ?

+2 A:

Either we're talking at cross-purposes (it's possible: I'm rather unfamiliar with OOP terminology) or you're missing a lot about functional programming. Modules and abstraction (i.e. interchangability) were basically invented in the functional language CLU. The seminal papers on abstract types are James Morris's Protection in programming languages and Types are not sets. Later, most improvements in module systems and abstraction have come from the functional programming world, through ML-like languages.

The killer application for functional programming is often said to be symbolic manipulation. Most compilers for functional languages are written in the language itself, so you could look up the source of your favorite functional language implementation. But pretty much any nontrivial program (functional or not) is written in a modular way to some extent — maybe I'm missing something about what you mean by “decomposition”? The modularity will be more visible and use more advanced concepts in strongly typed languages with an advanced module system, such as Standard ML and Objective Caml.

Gilles 2010-09-23 00:43:04

Yes, I'm still new to FP. No I don't mean modules as vehicle of (memory) protection. I rather mean that module is something you could replace. In strongly typed languages it's interface of a component. I will have look at code of compilers. It leads me to questions about FP-immutability vs. AST and FP-no-side-effects vs. code files, I wonder if that would be good/nice example of FP code. Anyway thanks a lot.

Pavel Savara 2010-09-23 19:17:29

@Pavel: I didn't mean memory protection either. I was discussing modules = replaceable components and abstraction = replaceability (and module system = the part of the programming language that concerns modules). Functional programming, module systems and immutability are orthogonal concepts to a large extent, although they do work well together.

Gilles 2010-09-23 20:32:18

+4 A:

Some time ago I was learning F# and wondering about the same topics, so I asked about quality open source projects to learn from.

The reason why you're not seeing anything similar to dependency injection in functional programming is that it's just "natural", because you "inject dependencies" just by passing or composing functions. Or as this article puts it, "Functional dependency injection == currying", but that's just one mechanism.

Mocking frameworks are not necessary. If you need to mock something, you just pass a "stub" function.

Mauricio Scheffer 2010-09-23 04:10:28

Good pointers, good direction. Let me discuss it a bit. It seems you propose to pass components-function on root method call. With hundreds of components I usually compose in real-world OOP application it would be difficult. Currying article suggest that you could let language to pick components from local context (?closure?). Right, but I can imagine only hierarchical contexts. Maybe I could pass in a structure containing named components (effective container) and resolve components-functions by name. But that's late binding/service locator. Am I reinventing something ? :-D

Pavel Savara 2010-09-23 19:35:23

@Pavel: honestly I haven't built anything of that scale in FP yet, but my experience so far with F# is that I don't feel any need for service locator / IoC, and take this from someone that is a real IoC junkie in OOP :-)

Mauricio Scheffer 2010-09-23 19:53:42

@Pavel: maybe it's because "dependencies" in FP are actually just functions so they become much more fine-grained, i.e. instead of passing a full IRepository, if you need to save an `Entity` you just pass a function `Entity -> unit`, which is trivially swappable with anything that complies with that signature.

Mauricio Scheffer 2010-09-23 19:55:58

@Pavel: finally, if you're recently starting out with FP I recommend trying to forget all about DI and other OOP patterns, and just go with it. As usual, the best way to learn is just doing it.

Mauricio Scheffer 2010-09-23 20:03:24

ansaurus

tags:

views:

answers:

Decomposition (modularity) in functional languages

related questions