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

[Jon Harrop <jon@jdh30.plus.com>]

On Thursday 03 February 2005 21:16, Thomas Fischbacher 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:

> On the other hand, I cannot just have e.g. a function like 
> POSITION-IF that returns a number or nil. (Either one has to work with
> exceptions, or wrap things up using the Maybe monad. Exception techniques
> may interfere badly with tail recursion in some cases.)

I think you will find that "int option" does exactly what you want whilst also 
statically type checking the result.

Let me recite my personal experience with static type checking. A couple of 
years ago, C++ was my latest language. I developed a significant project in 
C++ until I realised that the core of my implementation was fundamentally 
flawed and needed rewriting in order to achieve my objectives. This rewrite 
would have taken over a month. Thus, I gave up. Later, I decided to learn 
ocaml and porting my project seemed like a worthy task. The ported code was 
1/4 as long and almost as fast. I've made two more fundamental changes since 
then, both of which would have been infeasible in C++.

When using C++, I always had to restrain myself from making major changes, as 
they were bound to break the program and were often irreparable. In contrast, 
when I make a fundamental change to the ocaml implementation, the static type 
checker immediately leads me to all of the new misuses of the altered code. 
This allows me to make much deeper changes without having to worry about 
spending months debugging the surrounding code. The last time I made such a 
change it took a day to get the program working again, rather than a month.

Thanks to all these major changes, the latest ocaml version is vastly faster 
than the old C++. :-)

> (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".

> (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.

I shall remain skeptical that GCaml improves upon this solution this until I 
get to write a decent-sized project in GCaml. I am keen to see GCaml though.

> Furthermore, it seems a bit 
> inconsistent, as on the other hand, we have e.g. < and not </.

The arithmetic operators have types '_a -> '_a -> '_a for some 'a whereas the 
comparisons have types 'a -> 'a -> bool for all 'a. This is because 
arithmetic operators are well-defined for some types (e.g. int and float) but 
there are well-defined comparison operators for all but some types (i.e. 
except closures). Hence the use of monomorphic and polymorphic types (and 
exceptions), respectively.

Again, this has already been discussed at length on the mailing list.

On Thursday 03 February 2005 23:22, Thomas Fischbacher wrote:
> > type position = Position of int | None;;
>
> That is isomorphic to a straightforward application of the Maybe monad,
> I'd say. After all, you are just boxing up your int here. Furthermore, you
> have to define that particular type globally, as far as I understand it.

Use the "'a option" type defined in Pervasives.

> > 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.

On Thursday 03 February 2005 23:39, Richard Jones wrote:
> On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml
> > strings have this stupid limitation to 16 MB, which means in particular
> > that if you serialize a truly large intermediate state of, say, a long
> > and complicated calculation which accidentally got a bit larger than this
> > limit (while you did not expect that), well...
>
> Got to agree with you on this one ...  At least we'll soon all be
> using 64 bit computers where OCaml doesn't suffer this limitation.

Yes. In the mean time, I'm using lists of O(1)-length strings, which is 
working well.

I'd obviously like more comprehensive standard library and bindings to other 
libraries but, as far as the core language goes, I vote for (for these 
reasons):

1. Arbitrary-length strings and arrays. (robustness)
2. Version- and type-safe marshalling. (robustness)
3. Compiler warnings when run-time type errors may occur, e.g. when 
marshalling a data structure which might contain a closure. (robustness)
4. Extensible strings and arrays. (asymptotic complexity)
5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity)
6. Dynamic code generation. (to ease compiler writing)
7. More optimisation, e.g. inlining across functors built-in to the compiler. 
(performance)

If there were a redesign, I'd ask for "string" as "char array" and 
monomorphisation of polymorphic functions. Perhaps the latter can be achieved 
with a preprocessor?

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

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.