Actually, the contemporary functional languages are still of von Neumann, i.e. with additional lazy evaluation (term reduction to normal form). This means, the computation on higher type objects are done there in a symbolic way.

The original idea of Backus was “programs as mathematical objects”, where the objects (like functionals) are not represented by names (terms) in computations.

Although symbolic computations make sense (like algebraic calculations), and the computations on higher order object can be done (via some equations) if they are evaluated to the primitive types, the intuition behind the functionals is that they are *objects* that can be constructed as concrete structures.

Such objects may be envisioned as programmable integrated circuits (FPGAs).

This may break the current paradigm in IT that only symbolic computations (term rewriting) can be done on higher order objects.

It seems that the hardware technology is still far from making possible to break the paradigm.

By the way, human brain is non-von Neumann. The recent advances in Neurobiology may shed some light on how non symbolic computations can be done, google

R. Douglas Fields. Glial Regulation of the Neuronal Connectome through Local and Long-Distant Communication.

From what you said, here is what I believe is a layered signature:

signature DICT = sig

signature KEY =

type t

val leq: t * t -> bool

end

type key = KEY.t

type val

type t

val find, ins, del…

end

And then a module implementing the signature could be created as:

structure Dict: DICT = struct

structure Key: DICT.KEY =

type t = int

val leq a b = a < b

end

type t = …

type key = Key.t

type val = string

val find, ins, del…

end

Is that correct?

From what I've seen, it's more common to create DICT as a module *parameterized* by a module of signature KEY, instead of containing a submodule of signature KEY.

]]>Both SML and OCaml have module hierarchies, under the terminology “substructures”. eg, when I have a substructure for keys in a dictionary. Think of that as Sigma k::KEY.DICT(k), for example.

Your example is a kind of corner case because the structure is, in fact, a value. In general evaluation of a structure expression can have an effect, and we wish to distinguish two abstract types that are observably different. The conservative thing to do is insist that such types always be distinct, even when we can see in particular cases that they are in fact indistinguishable. This leads to a simple, practical module system without the complications that would be required to do a better job in certain circumstances. OCaml tries to do better (“applicative functors”), but the costs outweigh the benefits, especially for expository purposes in PFPL.

]]>I’m having trouble figuring out a concrete example of module hierarchies in the chapter *Hierarchy and Parameterization*. Parameterization corresponds to functors in SML and OCaml (which I have been using to ground the concepts presented in the text), but it doesn’t seem like either of these languages have module hierarchies as defined. Is that true, or am I missing something obvious?

Second, I don’t understand why binding a sealed module to a variable allows us to safely access its static part. What is the conceptual different between

(struct type t = int val zero: t = 0 end : sig type t val zero: t end).t

and

let val M = struct (struct type t = int val zero: t = 0 end : sig type t val zero: t end) in M.t

Are modules variables “special” in some way?

]]>