Wish list for SML

Strings and Parsing

• Regex library
  • SML/NJ library: http://www.smlnj.org/doc/smlnj-lib/Manual/regexp-lib-part.html
• Parser combinator library
  • We now have one as 'parcom' in smackage (https://github.com/standardml/parcom)
  • SML/NJ library has parser combinators, see parser-comb.sml and parser-comb-sig.sml in Util
  • Moscow ML also have parser combinators, see https://github.com/kfl/mosml/tree/Rel-2.10/examples/parsercomb
• Unicode! (http://mlton.org/Unicode)

Web

• AJAX/JSON/HTTP/modern web technologies interaction
  • Skeletal JSON parser: https://github.com/standardml/SML-JSON
  • SML/NJ library has JSON parser, see JSON directory - depends on ml-ulex for lexing, which seems a bit heavy handed
  • SML/NJ library has HTML parser, see HTML directory (latest version with XHTML and HTML4 support not yet ported to MLton)
  • Google's Gumbo HTML5 parser - https://github.com/kni/sml-gumbo-parser
  • http://stilts.j4cbo.com/
  • REST services consumer library
  • Websocket (http://dev.w3.org/html5/websockets/) client/server
    • http://socket.io
  • API for parsing/unparsing/quoting URLs (There's a simple library, which should conform exactly to the RFC, at https://github.com/finrod/uri (requires parcom))
  • API for parsing/unparsing/quoting XML/HTML/SGML
• Man, http://www.smlserver.org/ seems great but Rob's tried installing it like four times and has never succeeded.

Networking

• Prettier networking
• High performance Event-based IO for network services and the like (libevent bindings, maybe?)
  • https://github.com/kni/sml-ev
• Libcurl? (http://curl.haxx.se/libcurl/c/)
  • In smackage as 'curlsml' (https://github.com/standardml/curlsml)
  • https://github.com/kni/sml-curl
• Thrift RPC http://en.wikipedia.org/wiki/Thrift_(protocol)

Graphics and GUI

• Modern, idiomatic GUI library (preferably not yet another abortive GTK+ bindings)
• OpenGL bindings
  • see SML3d, http://sml3d.cs.uchicago.edu/
• CUDA bindings

File formats and storage

• Interfaces to various modern file formats
  • Make sure that they support a common interfaces (and a ""factory"" that chooses the right implementation)
    • Bitmap Image Loader (SVG, PNG, GIF, JPEG)
      • SML3d has PNG loader
    • Bitmap Image Serialiser (PNG, GIF, JPEG)
    • Audio Loader/Serialiser (WAV, MP3, AU)
    • Stream Adapter (gzip, bz2, deflate, base64 (de/en)code, uu(en/de)code)
    • Archive (zip, tar, jar)
    • URL Opener (http, ftp, imap, pop, data)
    • File opener (URL Opener, Stream Adapter, eg open /tmp/foo.zip/bla)
• Interfaces to various popular SQL (and NoSQL?) databases (http://smlweb.sourceforge.net/smlsql/?)

Parallelism and Concurrency

• Parallel Map/Reduce (a la Hadoop?)
• Atomic locks. Mutices, condvars, rwlocks, etc.
• Real threads (none of that fake CML nonsense)
  • http://sss.cs.purdue.edu/projects/multiMLton/mML/Welcome.html
  • See also Manticore (http://manticore.cs.uchicago.edu/papers/ml07.pdf and other stuff)
• MPI support (http://sourceforge.net/projects/sml-mpi/)

OS

• Bringing OS-specific support up to date with the last 14 years worth of OS developments?
• Installing signal handlers
  • every SML implementation seems to have this, we just need a standard interface
• GNU Readline support (https://github.com/standardml/readline)

Utility

• Smackage (an SML package system)
  • Semantic versioning library (http://semver.org/)
• Interfaces to various crypto and hashing algorithms (e.g., libssl?)
• Packaging SMLDoc from SML# (http://www.pllab.riec.tohoku.ac.jp/smlsharp/?SMLDoc) to make it more readily available as a stand-alone tool.
• Libraries for fast data structures? e.g. 2D/3D matrices, queues, hashtables, etc.
• ncurses
  • Gian has done a little work towards this. If you feel like finishing it, talk to him.
• Let's make the vim sml indent Not Suck Anymore
• Wrappers/implementations of math+statistics libraries
• Standard ML highlighting for common source code highlighters
  • GeSHi
  • SyntaxHighlighter
  • gedit
  • Pygments
    • This exists (it's how GitHub highlights SML) but it needs some work

Packaging

• test RPMs of SML/NJ 110.73 for Fedora 15 x86_64 users
  • see https://bugzilla.redhat.com/show_bug.cgi?id=670088

We should possibly think about how we avoid namespace collisions and how we structure libraries such that they can be used with one another in a fairly seamless way.

Sources of Inspiration and/or code

• http://tom7misc.svn.sourceforge.net/viewvc/tom7misc/trunk/ - miscellaneous core library, basis extension, algorithms, and file format library snippets (GPL/LGPL)
• http://www.hardcoreprocessing.com/Freeware/StandardMLCode.html - mini projects/libraries CompatibilityLayer, ErrorHandling, Arith, Geometry, Matrix, Collections, NumericRep, FunctionalIO, ParsingToolkit (LGPL)
• http://bangmoney.org/projects/sml/ - HTTP, URI, and Windows INI libraries (BSD)
• http://reallylongword.org/sml/ - GetOpt and VectorPair structures
• http://mlton.org/Libraries (which includes many links, especially these)
  • http://mlton.org/MLtonLibraryProject
  • http://mlton.org/cgi-bin/viewsvn.cgi/mlton/trunk/lib/mlton/
  • https://github.com/seanmcl/sml-ext (now forked to the standardml project)
• http://hcoop.net/~magnus/sml-libs/links.html - links to other libraries and bindings
• http://ocaml-batteries-team.github.com/batteries-included/hdoc/ - similar stuff in Ocaml
• http://ocaml.janestreet.com/?q=node/13 - other similar stuff in Ocaml
• http://successor-ml.org/ - language redesign effort

Things we would like to avoid doing

Preferably we won't work on language changes or compiler hacking. Why? Because that's where most of the effort has gone in the past 10 years, but it was not the lack of quality compilers that killed SML --- it was the lack of quality libraries for performing "real world" tasks. We should focus our attention on getting an eco-system of maintained, discoverable libraries first, and then figure out what else we would like to do longer-term.

How you can help

• Got some useful SML code rotting away in some obscure corner of the internet? You can drag it out, tidy it up and contribute it.
• Implement wishlist features or help resurrect abandoned libraries.
• Don't know SML very well? No problem! Writing FFI bindings for C libraries doesn't require a particularly deep knowledge of SML, but it's kinda tedious and many hands make light work.
• Also, porting libraries from ocaml is pretty straightforward. Haskell libraries require a bit more care, due to the lazy/strict divide, but are still fairly easy.
• Write documentation, tutorials etc.
• Publicity materials for SML. Start an SML community website! Design a front-end for the eventual package manager!
• ... suggest something!