Browse thread
RE: [Caml-list] Interactive technical computing
-
Robert Fischer
- skaller
- Jon Harrop
-
Richard Jones
- Michael Vanier
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Michael Vanier <mvanier@c...> |
| Subject: | Re: [Caml-list] Interactive technical computing |
I agree 100%. This is the biggest limitation to using ocaml for large projects. If it were fixed, ocaml would become an unstoppable juggernaut ;-) Here's a paper describing an approach to this problem for an extended version of Standard ML: http://www.ps.uni-sb.de/Papers/abstracts/missing-link.html This actually goes further than dynamic linking to provide a full component model. What I wouldn't give to see this in ocaml. Mike Richard Jones wrote: > On Thu, Mar 08, 2007 at 03:26:03PM -0600, Robert Fischer wrote: >>> Putting aside the obvious cultural resistance to using a sensible >>> language for this project, there is one technical hurdle: It needs to >>> compile into a DLL which can be linked to other programs (in C and >>> other languages). I can't generate such code using ocamlopt, at least >>> not without using unsupported out-of-tree extensions. >>> >> I don't think this is a real hurdle to general adoption of a language. >> After all, Java and C# aren't intended to be used like that, yet they >> certainly have wide-spread adoption. > > It is a hurdle because not all programming is writing end-user > application code. > > In fact what is somewhat sad is that OCaml (unlike Java and C#) can > compile to native code which really has very minimal "environmental > needs" - just a smallish library of functions and a GC which is > written on top of C's malloc. So really it could be an ideal > replacement for libraries written in C, where the heavy lifting is > done in OCaml and there are some thin bindings to provide a C API. > > Rich. >