[MLton-devel] MLton survey summary
Stephen Weeks
MLton@mlton.org
Thu, 16 Jan 2003 21:16:44 -0800
I thought y'all might like to see the current survey results. I'm
thinking I'll leave the survey up until the end of this month, since
we might get a few more responses. So far, we've had 23 responses,
and all but one of those had a valid email address.
occupation
10 programmer
5 faculty/researcher at university
3 undergraduate student
2 researcher at industrial research lab
2 graduate student
1 other
how long SML
4 [10, inf) years
8 [5, 10) years
5 [1, 5) years
4 (0, 1) years
how long MLton
1 4 years
1 3 years
3 1 year
6 (0, 1) years
largest SML program
1 100000
4 [20000, 51000]
4 [5000, 10000]
7 (100, 1000]
3 (0, 100]
largest MLton program
1 51000
1 10000
3 [100, 1000]
2 (0, 100]
Here are the improvements that people voted for.
10 new arch/OS
3 PowerPC + Mac OSX
1 MinGW
1 Windows
10 interfaces to libraries
1 Cocoa or Carbon
1 Gtk or QT
9 proper front end
8 debugger
8 additional optimizations
7 call from C
5 space profiler
3 compiler internals
2 c codegen
2 CML
1 additional integer or real types (Int64 ...)
Here are comments that people had in the other improvements area.
--------------------------------------------------------------------------------
IDL compiler, perhaps with COM like HDirect.
MinGW
--------------------------------------------------------------------------------
Compatibility with NJ/SML is important.
--------------------------------------------------------------------------------
Being able to call SML from C would enable general users to write interfaces to a >>lot<< of commercial libraries. eg messaging, gui toolkits etc.
--------------------------------------------------------------------------------
gcaml-like generics, and uncrippled native threads. also, the ability to have inline asm is necessary for some performance scientific computing work (for tweaking the fpu, for instance)
--------------------------------------------------------------------------------
Support of the Sml-NJ Compilation Manager to facilitate "porting" code developed with that compiler.
--------------------------------------------------------------------------------
And here are the responses that people had about applications they are
building.
--------------------------------------------------------------------------------
1. Text-transformation tools for XML (Python, Ocaml)
2. Text-filtering and content-analysis tools (Ocaml)
3. massively-multiplayer network game, currently being prototyped in
Ocaml
--------------------------------------------------------------------------------
I'm contemplating building a little Genealogy application (similar to
Geneweb -- a CAML application) with a GUI interface. To do so, I
would need access to some kind of GUI library (preferably Gtk,
wxWindows, etc.)
Things I like about MLton: Speed, final executable size.
Things I don't like: No interactive mode for experimentation, lack of
a debugger.
--------------------------------------------------------------------------------
There are a few situations where it be really useful to generate
native code compilers for a few domain specific languages for embeded
systems. We probably could get by with SML/NJ but just being to ship a
lean standalone executable would be quiet nice.
--------------------------------------------------------------------------------
A window manager. Concurent ML would bee very nice.
--------------------------------------------------------------------------------
I am overloaded for the time being, but I would at some stage like to
bind parts of OpenGL/GLUT onto MLton - a la my binding for Moscow ML.
We've exchanged emails before about this and the sticking point for me
is that I want to call back from C to SML. The trampoline workaround
makes me immediately run back to my nice, safe, convenient, quiche
eating copy of GHC!
Behind all this is my desire to have a good strict standardised
functional language compiler around in the event that the lazy
paradigm proves more trouble than it is worth. MLton seems to be a
very good compiler for that purpose.
--------------------------------------------------------------------------------
We currently have an automatic test script generation tool called ptk.
There's a brief mention at
http://www.research.avayalabs.com/user/wadler/realworld/ptk.html.
It's built with NJ/SML. We would compile with MLton if converting was
very easy and we gained better performance and access to tools for
time/space analysis and debugging.
--------------------------------------------------------------------------------
We are building an implementation of a refinement type checker for
Standard ML. Main consideration is how clean is the front end.
Secondary consideration is how easy it might be to propagate
refinement type information down the compiler for optimizations.
--------------------------------------------------------------------------------
I have wanted to try MLton, but I was always scared off by the
following passage from user-guide/Drawbacks_MLton. I cannot afford
the resources to have 2 ML environments installed; for me to switch to
MLton, it would have to be the only one. And, of course, I think that
static type checking is a essential feature of ML.
There is quite a bit of front-end type checking that is not done. If
you feed MLton a type-incorrect program, it might produce a terse
error message and exit or it might terminate and produce an
executable. Note that this does not mean that the behavior of an
executable generated by MLton is random. It simply means that the
compiler may behave strangely for invalid SML programs. The behavior
of MLton for valid SML programs is well defined.
It is strongly recommended that you type check your programs with
another SML compiler before compiling them with MLton.
--------------------------------------------------------------------------------
I am impressed the speed of Mlton that is excellent. I plan to build
a very large multiagent B2B software that is going to use Semanticweb
technologies, RDF parser, Web services and SOAP. Becasue Mlton doesn't
provide them, I will write an interface to Java/C/C++ classes to get
this functionality.
My first priority is an easy-to-use interface to Java/C/C++. Maybe in
future, after I got enough experience, I will rewrite these
libraries. But at start, I have to use them. Secondly, source debugger
and profiler are very important for commercial applications.
I don't know it is feasible, can we extend the compiler to use Java
classes easily? That will be wonderful.
--------------------------------------------------------------------------------
Our startup's product Reactis is an automated testing tool for
embedded software. The core of our tool is implemented using Sml-NJ.
The performance statistics for MLton that you have reported have made
us very anxious to try MLton. Unfortunately, the majority of our
customers use Windows, so (native) support for that platform is the
main hurdle preventing us from using MLton. Since our product is
commercial (and closed source) there are licensing problems with
deploying with cygwin. Support for the Compilation Manager would also
make it much easier to use both Sml-NJ and Mlton with big projects.
--------------------------------------------------------------------------------
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel