Re: [Caml-list] The boon of static type checking

[Michael Walter <michael.walter@gmail.com>]

On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > Are you using heavy casting and such without proper abstractions in
> > your C++ code?
> 
> No. The code is freely available here:
> 
> http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/smoke/index.html
Unfortunately I don't really have time to check that out to an
adequate extent :(

> > Pr what kind of changes did you want to make?
> 
> IIRC, one development was to change the core data structure from a list to a
> tree. The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC
> in stl_tree.h and stl_map.h vs 198 LOC in map.ml). My ocaml implementation
> uses trees and graphs throughout now.
Hmm, ok.

> > How did
> > you feel that the static type checker of C++ didn't provide you with
> > similar help?
> 
> As the C++ type system cannot represent (and, therefore, statically check)
> polymorphism properly, altering a generic data structure expressed using
> templates results in reams of errors, mostly pointing to wrong places. In
> contrast, the worst I get with ocaml is an error in the wrong place because a
> previous function has been inferred to have a wrong type. Even this problem
> is much less common and trivial to trace. Also, it would be even easier to
> solve with an IDE which threw up the inferred types.
Hrm.. it handles both subtyping and ad-hoc polymorphism. I agree, with
templates the error messages are not easy to read (it gets a lot
better with experience, but I understand that that is not an
argument).

> As the C++ type system cannot represent (and, therefore, statically check)
> modules and variant types, shoehorning solutions into using class hierarchies
> and being forced to use pointers results in verbose code and weaker type
> checking. In contrast, the equivalent ocaml code is succinct and thoroughly
> checked. This brevity can also be attributed to the ability to pattern match.
Admittedly the lack of modules is a bit of a pain (although one can do
very tricks by combing #include + templates to work around the lack of
macros :-). Also, the lack of algebraic data types/variants (besides
pointers a.k.a. T option;) in the core language is certainly bit
annoying. boost::variant<> appears to solve that problem very well,
though.

> Obviously such problems would have been virtually impossible to weed out had I
> chosen to use a language with dynamic type checking, which is precisely I why
> I left such languages at the door many years ago...
Although I'm using Python for a lot of my scripting purposes, I
definitely prefer statically typed languages for mid-size to larger
projects as well. Maybe I'm just weak, but the type system gives me
much (I second that other post which mentioned that static typing is
not only about type checking, but also about "compiler-verified code
documentation" and much more). :-)

> > > I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c
> > > = 1, 2, 3".
> >
> > It's a macro in Common Lisp (see [1]). In O'caml-ish syntax, it also
> > does "let a, b = 1, 2, 3" (3 is discarded) and "let a, b, c = 1, 2" (c
> > is bound to nil).
> 
> These seem pretty pointless to me, but what about:
> 
> # let {a=a; b=b; c=_} = expr;;
> 
> or
> 
> # let x = expr in
>   ... x.a ... x.b ...;;
> 
> and then
> 
> # let (a, b), c = expr, None;;
> 
> (if you must).
I was merely explaining its semantics (giving you a free google, so to
say ;-), without any judgement about its usefulness compared to O'caml
alternatives.

Regards,
Michael