Re: [Caml-list] syntax of private constructors in CVS version

[John Max Skaller <skaller@ozemail.com.au>]

Pierre Weis wrote:


> As you should already know, usual sum and product types in Caml
> correspond to the mathematical notion of free algebraic data
> structures. This is fairly useful and allows the modelization of a lot
> of common data structures in practical programming
> situations. However, besides the free algebra structures,
> mathematicians use a lot of non-free algebras (so-called structures
> defined via generators and relations). Private types aim at giving a
> way to modelize those non-free structures. Equivalenetly, you can
> think of private types as providing a way to implement types equipped
> with invariants, quotient structures (i.e. sets of equivalence classes
> for some equivalence relation on a free algebra), or data types with
> canonical normal forms.


Well said. If I may add: this can already be done using

classes, or abstraction of modules. However these tools
are much *too* heavyweight, because they also hide the
algebraic structure of the types completely.

The user then must provide all the accessor functions,
for example, instead of using record labels or pattern matching.

For immutable values, establishing an invariant at construction

time is enough to ensure the invariant is preserved: therefore,
it is enough to make construction abstract to ensure all values
of the type satisfy the invariants.

Just for interest, this is not the case for mutable objects,

for example:

	type rational = private { mutable x: float; mutable y: float };
	...
	let mess_up_invariant (z:rational) = z.y <- 0.0

Be interested to know the treatment of records with mutable fields.
Are they permitted? Or are the mutators disallowed?

> In conclusion: private types serve to modelize types with arbitrary
> algebraic invariants (no miracle here: you must program those
> invariants in the definition of the constructing functions).
> 
> In contrast with abstract data types, the private types still maintain
> the elegant pattern matching facility of ML outside the module that
> defines the type.
> 
> Hope this helps.


Indeed, a fine dissertation, and a good choice for an extension

as well. Thanks!

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners