On Wednesday 02 April 2008 23:50:54 Sylvain Le Gall wrote:
> On 02-04-2008, Jon Harrop <[EMAIL PROTECTED]> wrote:
> > I have already discovered many problems with F# but they are very minor
> > compared to the main problems with OCaml. While there is no theoretical
> > reason why OCaml cannot catch up (e.g. by leveraging tools like LLVM and
> > maybe the JVM's concurrent GC) I do not believe this will ever happen.
>
> FYI, even if it is not exactly what you expect, someone has ported the
> OCaml compiler to JVM (i.e. you ocamljava that replace ocamlc/ocamlopt).
> He has done a fairly huge amount of works to make it happen
> (http://ocamljava.x9c.fr/).
Yes, I have been following Xavier Clerc's work on ocamljava. I think this is a
very exciting project with awesome potential. The main problem appears to be
the JVM's lack of tail calls. Hopefully Sun will address this but they are
being remarkably lazy in doing so...
There is also the problem that ocamljava is likely to be a vanilla OCaml port
rather than an improved OCaml. So we are not likely to see operator
overloading added to ocamljava and so forth.
Regardless, I think the prospect of OCaml on a concurrent GC is reason enough
to convert to ocamljava.
Is there a Debian package for this project yet?
> Now, even if it doesn't have some downgraded performance, i must admit
> that the real problem when programming is not only performance but also
> ability to modify what you have written (expressiveness/clarity?). This
> help to create efficient implementation by being able to rewrite/check
> program in an efficient way.
>
> If people has the ability to write efficient and correct algo in ASM, i
> think we won't be here to discuss the issue about functor ;-)
Absolutely. In this context I would add another point. One of my long-standing
gripes with OCaml is its inability to statically check applications of
polymorphic comparison and hashing functions:
a = b
You can easily apply this to abstract types like sets and maps and get silent
data corruption because OCaml inappropriately uses structural comparison when
these types demand a custom comparison. In OCaml, you are required to
discipline yourself to choose the appropriate Set.compare function and so
forth. This is particularly a problem when developing a program and replacing
something like an association list with a functional map because you must
track down all occurrences of such functions and replace them by hand but
there are not even any tools to help you do this. This has caused me no end
of grief in the past, e.g. when I tried to improve the internal data
structures used by my mini Mathematica implementation only to be innundated
with run-time type errors that I was unable to debug.
F# has an interesting solution to this problem as well. F# does away with
functors and replaces Set.Make and Map.Make with univeral sets and maps but
these classes derive from the universal base class "obj" and override the
built in equality, comparison and hashing functions. Any attempt to use these
polymorphic functions like "=" then results in dispatch to the appropriate
comparison for whatever type you're acting upon. Moreover, the dispatch is
taken care of before compilation so the perfect comparison function is
inlined into the generated native code to give the best possible performance
as well as removing this important source of errors.
So F# has removed an important class of bugs by removing functors!
> I.e. functor are my syntactic sugar ;-) (always better than parametrized
> java class)
Well, compare this OCaml:
module Int = struct
type t = int
let compare = compare
end
module IntSet = Set.Make(Int)
Array.fold_right IntSet.add (Array.init 1000 (fun i -> 1+i)) IntSet.empty
with the F# equivalent:
set [1 .. 1000]
> Anyway, thank you for this interesting discussion about inlining. I know
> that someday i will come to F#... But since it doesn't run on Linux, it
> will take time for me.
Apparently F# does run under Mono but I have not managed to get it working
myself.
Unfortunately, Mono is really appallingly badly written and the authors of
Mono appear to have contempt rather than respect for people like Chris
Lattner (lead developer of the fantastic LLVM project). Given that pulling
off a project like Mono would require enormous talent, I can't help but think
that the future is bleak for that project. The package popularity results
seem to indicate that I am not alone in my belief:
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=mono-mcs%2Cocaml-nox&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"ocaml-developer" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/ocaml-developer?hl=en
For other OCaml forums, see http://caml.inria.fr/resources/forums.en.html
-~----------~----~----~----~------~----~------~--~---
