CODEWITHSUNDEEP
ocamlnaming-conventionsconventions
vog
vog

Reputation: 25597

What's the OCaml naming convention for "constructors"?

An OCaml module usually contains at least one abstract type whose idiomatic name is t. Also, there's usually a function that constructs a value of that type.

What is the usual / idiomatic name for this?

The StdLib is not consistent here. For example:

Upvotes: 3

Views: 445

Answers (2)

camlspotter
camlspotter

Reputation: 9030

Some people find this way of module design makes OCaml programming easier, but this is not a mandatory OCaml programming style, and I do not think there is no official name for it. I personally call it "1-data-type-per-1-module" style. (I wrote a blog post about this but it is in Japanese. I hope some autotranslator gives some useful information to you ...)

Defining a module dedicated to one data type and fix the name of the type t has some values:

Nice namespacing

Module names explain about what its type and values are, therefore you do not need to repeat type names inside: Buffer.add_string instead of add_string_to_buffer, and Buffer.create instead of create_buffer. You can also avoid typing the same module names with local module open:

let f () =
  let open Buffer in
  let b = create 10 in   (* instead of Buffer.create *)
  add_string b "hello";  (* instead of Buffer.add_string *)
  contents b             (* instead of Buffer.contents *)

Easy ML functor application

If an ML functor takes an argument module with a data type, we have a convention that the type should be called t. Modules with data type t are easily applied to these functors without renaming of the type.

For Array.create and Array.make, I think this is to follow the distinction of String.create and String.make.

  • String.create is to create a string with uninitialized contents. The created string contains random bytes.
  • String.make is to create a string filled with the given char.

We had Array.create for long, to create an array whose contents are filled with the given value. This behavior corresponds with String.make rather than String.create. That's why it is now renamed to Array.make, and Array.create is obsolete.

We cannot have Array.create in OCaml with the same behaviour of String.create. Unlike strings, arrays cannot be created without initialization, since random bytes may not represent a valid OCaml value for the content in general, which leads to a program crash.

Following this, personally I use X.create for a function to create an X.t which does not require an initial value to fill it. I use X.make if it needs something to fill.

Upvotes: 5

Daniel Bünzli
Daniel Bünzli

Reputation: 5167

I had the same question when I picked up the language a long time ago. I never use make and I think few people do.

Nowadays I use create for heavy, often imperative or stateful values, e.g. a Unicode text segmenter. And I use v for, functional, lighter values in DSL/combinator based settings, e.g. the various constructors in Gg, for example for 2D vectors, or colors.

As camlspotter mentions in his answer the standard library distinguishes make and create for values that need an initial value to fill in. I think it's better to be regular here and always use create regardless. If your values support an optional initial fill value, add an optional argument to create rather than multiply the API entry points.

Upvotes: 1

Related Questions