Multiple source files, directory structures, and namespaces in functional programming

Question

I was surprised to see that the source code for Hacker News is just one large file containing a flat list of function definitions. Git Hub - news.arc

Is this typical of functional programming? Is it unusual to have a source in many short files in a potentially deep directory structure, as is usually the case with OOP projects?

Are modules in FP the same as namespaces in OOP?

Answer 1

There are many functional programming languages ​​(FPLs), and they are very different. Like Lisp dialects (e.g. Scheme, Common Lisp, logo, Arc and others).

Often they are not organized around classes (or similar concepts), and classes are often not combined with namespaces.

In some object-oriented languages, programs consist of many classes, a class hierarchy (or something similar) is mapped to a directory structure, and each class is one or more files. This leads to software systems consisting of many files and IDEs that view these files / classes as a hierarchy. (this differs from the original Smalltalk, where code is accessed by browsers and not file-based).

In Common Lisp, for example, classes are not namespaces, and methods are not tied to individual classes (since there are several methods). There is a separate construct called "package" that provides namespaces for Lisp characters. There, a typical software system consists of files that combine several related functions. Usually a larger unit of functionality gets its own namespace.

For example, a graphical toolkit can have several namespaces: ui-backend, ui-user, ui-system, ui-drawing, ui-animation. The ui-drawing namespace can be used in several files: ui-draw-2d-objects.lisp, ui-draw-3d-objects.lisp, ui-draw-macroros.lisp and much more. A single ui-draw-2d-objects.lisp file will bind all the classes, methods and variables needed to draw 2d objects (lines, polygons, circles, bitmaps, ...).

Then the development system is responsible for navigation. But often navigation is not hierarchical, but based on the search and extraction of characters. Then it doesn’t matter how big the files are. More importantly, the files group the necessary functionality and are internally organized so that the related functionality can be identified in some way.

If, for example, I want to identify all the functions of drawing a rectangle, I would use REPL.

In LispWorks, drawing primitives are in the "GP" or "GRAPHICS-PORTS" package. Then I can ask LispWorks to tell me all the characters that contain "draw-rect" in the "GP" package.

CL-USER 10 > (apropos "draw-rect" "GP") GRAPHICS-PORTS::%DRAW-RECTANGLE (defined) GRAPHICS-PORTS::DRAW-RECTANGLE-BOUNDS (defined) GRAPHICS-PORTS::%DRAW-RECTANGLES (defined) GRAPHICS-PORTS::DRAW-RECTANGLES-BOUNDS (defined) GRAPHICS-PORTS:DRAW-RECTANGLES (defined) GRAPHICS-PORTS:DRAW-RECTANGLE (defined) 

The above list says that each of these characters has certain functionality, and those that have one colon are “exported”.

I can then use these characters to find additional information: an argument list, source code, documentation, and more. Generic Lisp even provides standard features such as DOCUMENTATION, DESCRIBE, and ED.

Thus, the development here is not based on many small files organized for a certain class hierarchy, but as a hierarchy of modules and namespaces, with each namespace combining a larger number of functions stored in one or more files. The IDE is then responsible for supporting non-hierarchical browsing and searching.

Answer 2

No, modular programming is quite common in FP. The same general principles of modularity are used.

In Haskell, for example, you can say

 import qualified Parsec as P 

which gives you the Parsec parsing library in the P namespace.

Whether modules and namespaces are "the same as namespaces in OOP" depends on your functional language and your OOP language. (ML modules are slightly different from other languages.)

Answer 3

Arc implementation language in which succintness is the main goal of the project. news.arc included in the Arc distribution of Arc and can be used to demonstrate this succinctness by packing a useful application into a single source file.

Such packaging does not necessarily indicate common practice in functional programming, although, as @Rainer (+1) notes, file boundaries are often less important in functional programming environments.