Possible Duplicate:
Functional Programming vs. OOP
How to write manageable code with functional programming?

In OOP, your basic unit of organization for code is the class. A frequently used methodology in Java, C# and similar languages is to organize your code around having one file for each class with the file name following the class name.

You can consider each of these class as a unit of organization to group a single concept.

These classes are in in namespaces which often follow the directory structure of the files in the solution/project. Namespaces are another level of organization.

How are large projects in functional languages typically organized?

How to you determine how to split your functions into different files?

Are other units of grouping beside files used?

How is code typically organized within a single file?

  • 18
    @S.Lott What's stopping you from... Years and years of programming with a completely different mindset, to the point that Haskell code doesn't mentally compute. And of course you are assuming that real projects are always correctly and neatly organized (maybe they are but how's a noob like me to know?)
    – yannis
    Commented Nov 30, 2011 at 3:03
  • 14
    @S.Lott: I have always programmed in OOP. I have started dabbling in functional languages very recently out of curiosity. You say: "Why ask here?". A: To get some mentoring and insight from people with experience (or experts as the site puts it) who could enlighten me on the subject. Isn't that the purpose of this site? Can't all Programmers or SO questions be replied with: "why don't you find out for yourself"? The answer is yes, you can. But the reason to ask the question is to get better/faster results from someone who is an expert on the subject.
    – Gilles
    Commented Nov 30, 2011 at 3:25
  • 5
    @S.Lott: if he just reads random code, how will he know whether the organizational decisions they have made are good ones or bad? And why they are good or bad? Commented Nov 30, 2011 at 4:33
  • 1
  • 4
    @S.Lott To summarize, having an expert in the language or paradigm identify a well organized project, identify any weaknesses/shortcomings that might exist in the organization, and explain why is far more valuable than just reading the code and looking at the organization, with the assumption that it's well structured.
    – Thomas Owens
    Commented Nov 30, 2011 at 13:53

1 Answer 1


I suspect this depends on language. As far as functional programming, I have mostly dabbled in Haskell, so I'm going to explain how it works there.

Haskell code is organized into "modules" which are basically just collections of functions and data types. Each module is a single file. A module is something of a mix between a Java class and a Java package--the exact scope of what a module does varies. A module also has control over which functions and type constructors to export, and which ones to hide; this is similar to private and public in Java.

In my own programs, I like to have modules do one thing, semantically; this makes them like a Java class except that they might define multiple data types. The modules I use from the standard library, like Data.List, are more like packages--they provide a set of similar utility functions. This is also very similar to static Java classes like java.util.Arrays.

The modules are also like Java packages in that they can be nested for clarity (I do not think this has any effect on the code itself). In general, for a single project, I give it a name (say Project) and have all of my modules be part of this (e.g. Project.Parse and Project.Run). If I was writing code that was more like a library than an application, I would organize it based on what it was doing, like Data.List or Control.Monad. One major difference from other languages is that Haskell encourages limiting IO and putting it all in one place. A large number of modules do no IO at all, and for any given project, I like to have as many modules be pure as possible.

As an example, I am working on a simple programming language I'm calling TPL (for no good reason). For this I have created two simple modules: TPL.Parse which defines the internal representation of the language and how to parse it, and TPL.Run which runs the interpreter and deals with variables and IO. For actually compiling and running the code, there is generally a Main module which is what ends up being the entry point of the program.

There is significant freedom in organizing the functions within a file; this is just what I like to do. I define my data types towards the top, before they are used elsewhere. Right after defining the data types, I implement whatever I need to make them part of their appropriate typeclasses--this is sort of like implementing an interface. Then I follow with logic and various helper functions, as appropriate. Finally, I like to have all of my IO functions at the very bottom ending with main. This makes it clear exactly what is doing any IO and where the program starts.

So, in summary: functions are contained in modules, each of which is made up of a single file. Several modules can make up a program or library; the former generally includes a Main module that is its entry point. Within a file, there are different options for organization, but I prefer to group data types near the top, IO near the bottom and logic in the middle.

  • Long shot since this is such an old answer but do you have an example folder structure that would be standard in Haskell. I specifically wonder if they make a distinction between IO folder name/level with pure ones
    – Ced
    Commented Feb 10, 2023 at 23:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.