Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>]

On Fri, 4 Feb 2005, Jon Harrop wrote:

> > (3) The type system is annoying. People claim it helps catching errors,
> > but my impression is it only catches those which I would never make
> > anyway.
> 
> Static type checking is completely fundamental to OCaml. Consequently, I think 
> that's a really silly thing to say here but your next comment implies that 
> you don't know what static type checking is for:

Well, I might want to differ here, but I should perhaps also add that I 
indeed do only know about as much about the structure of the 
Hindley-Milner-like type system of Ocaml as is the common subset of 
Haskell, SML/NJ and Ocaml.

Yes, it's fundamental to those languages, and indeed I originally thought 
this would be a great thing, years ago, when I came to SML/NJ from C++. 
Right now, after a few years of Lisp experience, my personal impression is 
that actually, it is more a hindrance than a help. But of course, one may 
always say that we Lisp hackers just are spoilt by our language in this 
aspect. By the way, Paul Graham seems not to like the ML family for about 
precisely the same reason.

One issue with the type system is that, looking closely, there are at 
least two (perhaps three) very different tasks it tries to do, which 
superficially look like being the same, but actually are very different, 
and indeed, in many situations, it may be much more appropriate to 
address them specifically and individually than with an unified approach.

(1) Prevent the programmer from "accidentally plugging an electrical 
shaver into a power high-voltage outlet".

(2) Give the compiler hints how to optimize certain manipulations in terms 
of machine instructions.

Concerning (1), from the machine point of view, there is no difference 
between a floatingpoint number representing a length in meters and a 
floatingpoint number representing a length in feet. Nevertheless, one 
should not blindly add the one to the other, as NASA by now surely can 
tell you. And indeed, the system of physical units, be it SI or something 
even more elaborate, exists precisely to prevent such problems, yet there 
are aspects of this "type system", which has proven its value, which can 
not be mapped to Hindley-Milner.

If I multiply a speed (in m/s) with a mass (in kg),
I get a momentum (in kg m/s), which I neither can sensibly add to a 
speed, or a mass. If I further consider a change in momentum with time, I 
automatically get something with units kg m/s^2, that is, a force.

Of course, I could introduce types for all intermediate quantities which I 
will encounter in a problem statically. However, there are many problems 
where I do not know a priori which quantities will appear with which 
powers, hence I would like to have this with full dynamical flexibility. 
Please prove me wrong if I am missing something here, but to me it seems 
that even for this simple "real-world type system" example, there is no 
way to directly map this to H.M. in the way explained here.

And this is only *one* example. There are many more, of structures that 
morally qualify as type systems, but cannot be related to H.M.

> > (4) There are a few other minor issues, such as a lack of
> > multiple-value-bind, which I personally find slightly annoying, but
> > not essential.
> 
> I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1, 
> 2, 3".

Let's take a specific example.

* (/ 1234 100)

617/50
* (round 1234 100)

12
34

The division function in LISP returns one value. The ROUND function 
returns two. If I use it as in 

* (+ 5 (round 1234 100))

17

it behaves as if it were a function that gives me only the primary value. 
But if I want it, I also can bind and process the secondary (or even 
higher) extra values returned by that function.

So it's even more than "just returning more than one value without having 
to cons" (which already is quite nice - but this essentially can always be 
emulated via going to CPS, which establishes full call/return symmetry). 
It's about giviny gou extra choice. Either: "Nice that you can also 
provide me extra information, but I really don't care here", or: "I can 
as well make use of this other piece of information which you 
already obtained anyway." Same function, same call.

> > (9) It really annoys having +, +., and +/.
> 
> There is a trade-off between type checking and operator overloading. This has 
> been discussed at great length before and a lot of interesting information 
> can be found by perusing the mailing list archives.

Sure. I don't quite know what to think about Haskell's type classes, but 
superficially it feels quite much more convenient. Anyway, it may as well 
be here that the impression which one gets by working heavily with it is 
a different one, so I'll keep an eye on that but surely not take it as the 
only True Revelation.

> > > I don't see how this and Printf are substantially different (except that
> > > Printf is type safe),
> > > could you elaborate?
> >
> > Erm, what do you do if you want to quickly debug-print a list of vectors
> > of pairs?
> 
> Use the top-level.

That entirely misses the point!

I talked about getting debug traces from an involved run.

> Anyhow, despite these few and minor shortcomings, OCaml is by far the best 
> language I have ever come across.

Nice if it suits you well. I personally experience some friction with 
it, however.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)