Browse thread
[Caml-list] Polymorphism and the "for" loop
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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.) cheers, William ------------------- 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