## Unifying functions and functors

I recently came across the PML language, which aims to realize "the great unification between records/structures/modules/objects and functions/functors/methods". Sounds great, but it lead me to wonder exactly why there is a distinction between functions and functors in the first place.

Is this simply because in all current languages, the module language is separate from the term language? Does anyone have any references on functors that might clarify why functions and functors are currently distinct? Given the explanation of categories in the last link, I might hazard that functions are arrows/morphisms mapping objects within a single category, and functors map objects between different categories, ie. functions operate on objects within a category, functors on entire categories.

If that's accurate, then would "the great unification" involve reifying categories/modules at the term level somehow? If not, what does this "great unification" involve? The only reference to "functor" in the PML manual is on page 8:

/\id:a -> b : dependent types are allowed in PML. They are useful to write the type of functors: functions
that handle structures with type in their fields. Here is an example of such a dependant type with a value of
this type:
type F = /\s:{ type p = [ A[] | B[] ] val q : p } -> s.p
val f:F s = s.q

Any clarification is much appreciated. :-)

## Comment viewing options

### After much searching...

The differences between functions and functors is discussed somewhat in the following papers:

Indeed, the separation between the core language and the module language result in this distinction. If modules were promoted to first-class values in the core language, then functors become simple functions. The first paper was particularly illuminating on this point. I was also recently pointed to Moscow ML which supports first-class modules.

### Modules

The distinction between functions and functors is mainly a consequence of the distinction between records and structures, and the fact that the latter are second class.

The reason for the strict stratification between core and module language is partly historical (traditionally, there was little use for something like first-class modules), and more seriously because modules require a much more expressive type system, with a form of dependent types and no chance for type inference, but strong termination for evaluation. To keep things simple and predictable, you separate the two sublanguages.

Personally, I believe that we will see this distinction becoming less and less visible in future language designs.

### Personally, I believe that

Personally, I believe that we will see this distinction becoming less and less visible in future language designs.

I agree. Reifying modules/structures as records would be very useful, but it might have negative performance consequences, since function application now involves a pointer indirection (via the record) instead of a static call. This is essentially a dispatch problem, which has been studied extensively in object-oriented literature, so there is likely an analysis which can statically resolve many of the indirections.

### Indirection

function application now involves a pointer indirection (via the record) instead of a static call

I don't think it would make any difference in that respect. In most compilers, functors are translated into functions in the intermediate representation anyway. Static evaluation of functor applications is a form of partial evaluation optimization that some compilers perform. For those second-class cases where you do it now there is no strong reason why it couldn't still be done when you make modules first class technically.

### How do (g)beta patterns fit

How do (g)beta patterns fit into this discussion?