Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Polymorphism and the "for" loop
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-10-22 (08:13)
From: William Lovas <wlovas@s...>
Subject: Re: [Caml-list] Polymorphism and the "for" loop
On Fri, Oct 22, 2004 at 08:38:49AM +0100, Jon Harrop wrote:
> On Friday 22 October 2004 07:19, skaller wrote:
> >  type void = []
> Why not "`void"?

"unit" and "void" do not denote the same type -- the former is the type
containing one element, whereas the latter is the type containing *no*
elements *at all*.  To emphasize this intuition, the types "unit" and
"void" are often written as "1" and "0" in the literature.

> > ...I consider that a bug...
> I'd have to go right ahead and disagree with you there. Surely a "procedure" 
> returns no information, which can be achieved by returning the only value 
> from a type representing a singleton set, i.e. _the_ value of the type unit.

Well, a "procedure" *does* return some information -- the implicit
assertion that it completed!  (And in doing so, carried out any side
effects that it might have had.)  The only way to do this in O'Caml is
to return some value.  In the case of a function executed solely for its
effects, we conventionally choose the trivial value (), but any value
would serve as well.

"void" would be another story altogether: Since there are no elements of
type "void", a function returning that type can never return at all, so
it's not really the right idea for "procedures" (or, more precisely,
functions executed solely for their effects).  I don't see the value in
hijacking the type "void" and imbuing it with a new meaning when we have an
appropriate "procedure" return type already...

(Incidentally, O'Caml doesn't really need a type "void" since it can convey
a similar semantic notion using polymorphism.  Consider the function raise,
which has type "exn -> 'a" -- in other words, given an exception, it
produces an arbitrary value of any type.  Since such a thing is impossible
(using the type-safe core language), we must conclude that raise does not
return to its call site when it executes.)


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: