I don't agree with either of the claims in your comment.

Although the GoF Abstract Factory pattern doesn't rule out having mutable state in your factory object, that is neither necessary for its purpose nor common practice when applying it in OO programming languages. The example in GoF is MotifWidgetFactory (for shitty Unix GUIs) vs. PMWidgetFactory (for shitty OS/2 GUIs), and in fact GoF says, "An application typically needs only one instance of a ConcreteFactory per product family," suggesting that they were thinking of cases where the factories don't even have immutable state such as the `terms` argument to `amb`.

They do explore a "prototype-based" factory that is stateful—but there the statefulness is just used as a way to configure the factory at startup, by building up a "product catalog" in it. Creating products doesn't modify the factory's state, and you could configure the "product catalog" just as easily by passing it in as an argument when the factory is instantiated; it's just that, in Smalltalk, that kind of thing is normally represented by segments of executable code that invoke a long sequence of side-effecting methods, rather than by data structures.

(You can also represent that kind of thing invoking a long sequence of pure functions, as in the "fluent interface" pattern that became popular with JQuery, but that isn't the Smalltalk way to do things, especially in 01994.)

The GoF examples other than the prototype factory are WidgetFactory and MazeFactory; in InterViews, WidgetKit, DialogKit, and LayoutKit; and in ET++, WindowSystem. Kerievsky's examples in Refactoring to Patterns (where he points out that people constantly conflate the various "factory" patterns, and that the lines between them are somewhat vague) are HTML parser AST node creation, ORM attribute descriptor creation, java.util.SynchronizedCollection and UnmodifiableCollection, and an OutputBuilder interface that allowed him to create either DOM nodes or XML output from the same unit test code. In all of these cases except the OutputBuilder, the factory objects are stateless.

So, by your definition that a factory is what you get if you take a function and add mutability, we find that 6 out of 7 of the GoF examples of "factories", and 3 out of 4 of Kerievsky's examples of "factories", are actually "functions" rather than "factories". I think this clearly shows that the categorization you propose does not coincide with the scriptural explanation of what "factory" means.

⁂

It's true that, in the case where there's no state, you can do this with just a pointer to a function. But pointers to functions don't exist at all in languages like Java, and aren't first-class values in languages like Pascal, where they are subject to various restrictions that keep you from using them like this.

Even in languages like C, which have first-class function pointers but not closures (except as a GCC extension subject to Pascal-like restrictions), you can't create new function pointers at run-time. So in C, or C++, you can replace a singleton factory like the ones GoF considers usual with a function pointer, or maybe a record of function pointers. But you can't write a factory factory that way, much less a factory factory factory.

So, while you're right that in a sense an immutable factory "is just" an indirectly-invoked function—that's the main point of my comment—if you want to do that in a language like Smalltalk or C++ (at least in 01994, when they wrote the book) or Java (at least in 02000), the Abstract Factory pattern in GoF tells you how to get it working.