[MLton-devel] 2003 survey final results
Stephen Weeks
MLton@mlton.org
Sat, 1 Feb 2003 09:46:12 -0800
I've turned off the survey. Here are the final results. There were
31 responses, which was certainly more than I would have predicted at
the start.
occupation
14 programmer
6 faculty/researcher at university
4 undergraduate student
3 graduate student
2 researcher at industrial research lab
1 other
1 project manager/CTO
how long SML/Caml
6 [10, inf) years
8 [5, 10) years
11 [1, 5) years
4 (0, 1) years
how long MLton
6 [2, inf) years
3 [1, 2) years
9 (0, 1) years
largest SML program
3 [100000, 150000]
6 [20000, 51000]
6 [1000, 10000]
7 (100, 1000]
3 (0, 100]
largest MLton program
1 150000
1 51000
1 10000
3 [1000, 5000]
3 [100, 1000)
3 (0, 100]
Here are the improvements people requested.
16 new platform
13 proper front end
12 interfaces to libraries
10 debugger
9 additional optimizations
8 call from C
8 space profiler
3 compiler internals
2 c codegen
3 CML
2 additional integer or real types (Int64 ...)
2 NLFFI
Here are the additional improvements people requested.
--------------------------------------------------------------------------------
- -compile-fast switch, that disables optimizations in order to
produce a binary as fast as possible (without regard to code
size/speed). The biggest drawback to a whole-program compiler is
recompilation time, and this hurts during development/testing. (Using
NJ to test the program usually isn't possible for me because of my
heavy use of FFI.)
- Dependency analysis a la CM
- Making the _ffi a bit more well-defined would be nice; it's been a
moving target for a few years, and some of the things I do with it I'm
not sure are legal. (I use monomorphic arrays and vectors like
CharArray.array, which work but aren't listed in the documentation.)
For me, the simplicity and reliability of the FFI is one of the most
useful aspects of mlton.
- Ability to disable load-world for my binaries. (For instance, if I
produce a suid executable on unix, I definitely don't want users to be
able to load-world for it!)
- (wishful thinking) It would be really good to have a centralized
repository for SML code and libraries similar to perl's CPAN.
--------------------------------------------------------------------------------
I'm very keen on a space profiler.
I also think it would be very cool to be able to compile Objective
Caml with MLton. (I am a somewhat unhappy user of OCaml.)
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
- XML parser (not validator)
- databases (MySQL, BerkeleyDB, PostgreSQL, SQLite) interface
- in the FreeBSD port Makefile, add the possibility to use SML/NJ
instead of a pre-compiled version of MLton to bootstrap MLton.
--------------------------------------------------------------------------------
good type-error messages. This is one of the main reasons why I don't
use SML more regularly today, and I use Scheme instead.
--------------------------------------------------------------------------------
Here are the responses that people had about applications they are
(thinking of) building.
--------------------------------------------------------------------------------
We're working right now on porting the software for the Concert
project (http://www.cs.cmu.edu/~concert/) from O'Caml/Popcorn/C/TAL to
MLton. The O'Caml version was very unreliable due to problems with its
threading library interacting with FFI poorly.
Best features of mlton for this project:
- Easy to build redistributable binaries for linux, windows
- Simple, dependable FFI
- Excellent performance
Being able to call MLton-compiled functions from C would have made the code a bit easier to design, but we worked around it.
MLton rules! Keep up the great work!
--------------------------------------------------------------------------------
Quick C-- compiler at cminusminus.org, currently built with Objective Caml :-)
I have some other large codes that I've avoided building with mlton
because 1. they're deeply embedded into SML/NJ CM and 2. I unknowingly
used some sml/nj extensions and it's a pain to find them and scrub
them out. (Real reason 3. is that the project is in limbo right now.)
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Web development/content management system that uses a template
language for interfacing with ML code; uses CML, and requires good
error messages from compiler to avoid pulling out hair =)
--------------------------------------------------------------------------------
I have several data-mining and information-retrieval applications
already coded in Scheme, that I may well be getting a chance to deploy
in the near future. Since SML is the most readable language I have
ever worked with (possibly exceptin Smalltalk), I would prefer to
deploy them in SML, so that I have a hope of getting other engineers
at the company to be able to maintain them...s-expression based
languages tend to scare people off.
--------------------------------------------------------------------------------
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel