[MLton] Vendor branches (for maintaining ckit, mlnlffi, etc... ports)

[Matthew Fluet]

> Have you considered using vendor branches, see
>   http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html
> for maintaining the various external library and tool ports to MLton?

It is a possibility, although I haven't thought about it alot.  I also 
note that SML/NJ has moved to using Subversion for development, so vendor 
branches and/or external definitions are possible ways of tracking 
changes.

> I was thinking about trying to add support for calling conventions
> specifiers (__stdcall, __cdecl) to ckit and mlnlffigen.

That's a fine extension.  But, I'll point out that while ckit is imported 
from SML/NJ as a tarball/patch pair, mlnlffigen (and mlnlffi-lib) has 
permanently "branched" from the SML/NJ sources.  Note that ckit is 
essentially pure Standard ML with the patch eliminating the SML/NJ 
extensions.  On the other hand, mlnlffigen is intimately tied to the FFI 
ability of the target compiler, so trying to maintain a small patch is 
farily painful.

MLRISC and SML/NJ Library both fall into the tarball/patch category, while 
CML falls into the "branched" category; again, the former are simply 
patched to remove SML/NJ extensions, while the latter is intimately tied 
to the control flow features of the target compiler.

I'm actually in favor of migrating mllex and mlyacc from "branched" to 
tarball/patch, since there aren't (many) target compiler dependent aspects 
of these programs.

Also, I find the tarball/patch category more transparently "honest" in an 
open-source sense.  It is a lot easier for those browsing the code to 
realize that these directories contain borrowed code.  I know the LICENSE 
file makes this all pretty clear, but I rarely (if ever) read the LICENSE 
files of other projects.

> From my perspective, one nice thing about using vendor branches would be
> that I could develop the extensions "as usual".  I wouldn't have to use
> any special patching techniques, take extra copies of the sources or
> remember not to use make clean.

I'm all in favor of making development easier.  I've essentially cobbled 
together a few scripts for updating the ckit, MLRISC, and SML/NJ Library, 
which avoid the problems you note above about losing changes after make 
clean.