3 ms·

Functors tend to be the big thing that's missing, right? F# just had to drop the feature because of compatibility with .Net packages, as I understand, but it se

by tel 11y ago

Functors tend to be the big thing that's missing, right? F# just had to drop the feature because of compatibility with .Net packages, as I understand, but it severely cripples the module system. MLs are such that the value-level stuff and the module-level stuff are more or less independent. So you can go a long way just liking the value-level stuff without really caring about the status of the module-level stuff. But it's also a pretty big motivator for the design of ML. F# is at least weirdly missing out here.

cwyers 11y ago
Can you provide an example of how functors make Ocaml code different from F# code in practice?
- tel 11y ago
  Sure. I'm not super familiar with F#, but I can state things which depend upon functors. A good example is the Set.Make functor in the OCaml stdlib. Elements in a Set must be orderable for efficiency's sake, so to construct a Set you parameterize it over a module specifying not only the type but also its ordering. module type Set = sig module type OrderedType = sig type t val compare : t -> t -> int end module type S = sig type elt type t val empty : t (* ... *) end module Make : functor (Ord : OrderedType) -> S with type elt = Ord.t end Here the OrderedType module signature represents any type that also has an ordering. The S signature represents the result signature of calling the Make functor which is passed any OrderedType-substantiating module and uses it to construct the (Set.S with type elt = Ord.t) module.
a-nikolaev 11y ago
Just to add to the discussion of these two language levels, there is a new research language called 1ML that unifies both levels: http://www.mpi-sws.org/~rossberg/1ml/ http://www.mpi-sws.org/~rossberg/1ml/ "a redesign of ML in which modules are truly first-class values, and core and module layer are unified into one language. In this "1ML", functions, functors, and even type constructors are one and the same construct; likewise, no distinction is made between structures, records, or tuples."

by tel 11y ago

cwyers 11y ago

Can you provide an example of how functors make Ocaml code different from F# code in practice?

tel 11y ago
Sure. I'm not super familiar with F#, but I can state things which depend upon functors. A good example is the Set.Make functor in the OCaml stdlib. Elements in a Set must be orderable for efficiency's sake, so to construct a Set you parameterize it over a module specifying not only the type but also its ordering. module type Set = sig module type OrderedType = sig type t val compare : t -> t -> int end module type S = sig type elt type t val empty : t (* ... *) end module Make : functor (Ord : OrderedType) -> S with type elt = Ord.t end Here the OrderedType module signature represents any type that also has an ordering. The S signature represents the result signature of calling the Make functor which is passed any OrderedType-substantiating module and uses it to construct the (Set.S with type elt = Ord.t) module.

a-nikolaev 11y ago

Just to add to the discussion of these two language levels, there is a new research language called 1ML that unifies both levels: http://www.mpi-sws.org/~rossberg/1ml/ http://www.mpi-sws.org/~rossberg/1ml/ "a redesign of ML in which modules are truly first-class values, and core and module layer are unified into one language. In this "1ML", functions, functors, and even type constructors are one and the same construct; likewise, no distinction is made between structures, records, or tuples."