Re: beginning with ML

Vesa Karvonen wrote:
However, probably the most important thing I noticed during that
period was that fixing problems in O'Caml was not a priority to the
developers. For example, I noticed issues in ocamllex/ocamlyacc.
They used global parser state at the time --- probably still do ---
and that there was no convenient syntax for threading state
(functionally). Some guy (I forget the name, just google) ---
actually, I think there were *two* guys, independently of each other
--- had already written fixes for those problems, but the O'Caml
developers just ignored the patch(es). I also noticed the protective
and restrictive licensing of O'Caml:


http://camlcvs.inria.fr/cgi-bin/cvsweb/~checkout~/ocaml/LICENSE?rev=1.17.4.3.2.1;content-type=text%2Fplain

Yes. Lack of reentrant parsing was a problem for many people (not me) but
the inability to fix such problems is a much more serious concern, IMHO.

O'Caml's license prevents other people from distributing patched
versions of O'Caml.

Yes. You must distribute their original sources and your changes as patches
to be applied. I also fail to see how this helps anyone. There are tools to
help with such situations but why should we have to bother.

It looked like to me that O'Caml was going
nowhere and that its developers did not appreciate the efforts of
others to improve the situation. In fact, I was totally right!
Having checked just now, ocamlyacc still seems to use global state.

OCamlyacc has sufficed for my work but many people seem to have migrated to
Menhir, which offers many benefits including reentrancy:

http://cristal.inria.fr/~fpottier/menhir/

I actually like the camlp4 parsers but they need documentation.

You know, therein lies a design flaw! Oh, boy! The future of O'Caml
looks awfully bad and there doesn't seem to be any kind of progress
forward. I really prefer much more robust, better designed, and
engineered languages than O'Caml. With O'Caml you get the worst of
all world.

Except OCaml brings a considerable user base, who build lots of useful
library bindings, test the compiler and libraries, write tutorials and
books and so forth.

The only solution I can see is to wait until the INRIA team stop making
significant developments (which has arguably already happened) and then
persuade the distro package maintainers to ship a forked OCaml. In many
ways, that would be a great day. On the other hand, if Torben really can
build the foundation of a next generation technical computing platform in
only a few weeks maybe we should do that.

There are far more basic concerns than the one you cite as well. For
example, reading text files without stack overflows is a newbie nightmare.
There are FAQs, of course, but these routines should be in the stdlib (as
they are in .NET) and the basic constructs (like try finally) should be in
the language.

Trust me, I haven't even nearly exhausted my list of concerning
problems of social kind with the development of O'Caml or badly
designed and engineered aspects of the O'Caml language. And the best
part is that all of it is true. Until now, I've just preferred to try
and be fair. That is over now.

I find the objections you've cited in this particular post to be entirely
valid concerns. I'm not convinced by some of the other stuff and I believe
the best way forward is to retain compatibility with OCaml to make
migration to a new language easier for OCaml's now substantial user base.
This is partly out of "fear of the unknown". For example, how long would I
have to spend debugging equality issues if I ported the 250kLOC of Smoke to
an SML style? I have no idea...

This is what F# does, of course, but I'd like to see the same language
innovation going on in the open source community. I really believe there is
an awesome opportunity for ML here.

There is one more major concern that we have not mentioned: commerce. I am
more than happy to give away great free software but I think it would be
beneficial for everyone if the next ML made it easy to sell value-add
software (both end user and libraries). Perhaps Java is the best lesson
here (although they screwed the pooch with graphics, which gives us a great
opportunity to leapfrog them).

I'd like to be able to write source code implementing tools for technical
users (scientists and engineers) that has access to a standard API for
OpenGL and GUI (e.g. GTK), compile it to a not-easily-invertible form (like
OCaml bytecode) and sell it so that users can run it on Linux, Mac OS X or
Windows either as libraries to add capabilities to the REPL or as end user
software.

I'm not asking for any fancy security or licensing issues or anything, just
the ability to sell compiled code that runs reliably out of the box. We
tried selling OCaml binaries and ~20% of our customers could not run the
software due to binary incompatibility problems that led to segfaulting.
This is best solved (I believe) by pulling the relevant stuff into the
run-time. Binary compatibility issues are then shifted from the producer
onto the package maintainer who was already solving that problem anyway.

We should probably try to compile a list of features that we would all want
to see in a next generation ML.

Incidentally, what are people's feelings on type classes? Is ad-hoc
polymorphism enough?

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
.

Relevant Pages

  • Re: Statically AND Dynamically Typed Language ??
    ... Linux compared to Windows. ... many other individuals are earning a living from their own language ... I have only limited knowledge about OCaml. ... if you compile a non-trivial program to native ...
    (comp.lang.misc)
  • Re: c#.net or vb.net
    ... Both C# and VB.NET compile to the _same_ IL don't they? ... developers using any particular development tool might make the body of code ... for a particular project doesn't make the language itself more "powerful," ... although that situation might make it more popular. ...
    (microsoft.public.cert.exam.mcad)
  • Re: RAD vs. performance
    ... exactly the same for a dynamically typed language as it is for Ocaml? ... general philosophy behind dynamic typing, ... it doesn't matter if it complains at compile time. ...
    (comp.lang.misc)
  • Re: GoTo in Java
    ... >> far fewer bugs - in OCaml. ... >written in a dozen different programming languages, ... >the language of your choice. ... compile" to a different language. ...
    (comp.lang.cobol)
  • Re: Using obscure languages professionally?
    ... > Lisp, or OCaml, which compile any code you enter to machine ... > language, then print the result. ...
    (comp.programming)