Re: [MLton] ML hack evening ideas

[Jake Z. <ja...@zi...>]

While we're on the topic of editor/IDE support for SML:

> Additional IDE (esp. Emacs) support.  For example, MLton has a
> 'def-use' mode for emacs (http://mlton.org/EmacsDefUseMode), which I
> use quite a bit, but I wonder if it wouldn't be better to integrate
> with one of the general-purpose emacs packages for that purpose (e.g.,
> ctags, xref).  Similarly, I'd love to get some kind of completion
> support, presumably using the emacs company-mode package.

I actually recently ported the Emacs def-use mode to a Vim plugin
(https://github.com/jez/vim-better-sml). One thing that's nice about the way
MLton works now is that the def-use information is editor agnostic: it just
dumps the information in an easy-to-consume format. This means integrating
with
other editors is straightforward.

> One issue with IDE support for SML is that it is often difficult
> (if not impossible) to know the context in which a .sml file is meant
> to be used; it is implicit in the containing .mlb or .cm file.  So,
> unlike most languages, where upon encountering an identifier that is
> not bound in the file, one jumps to the top of the file to look at the
> #import or include directives, one needs to do more work with SML
> files.

I'd argue that at least the output of the def-use information makes this
point
not so important. For those unfamiliar, here's a sampling from a def-use
file:

    variable def1 /filename/foo.sml 1.1
        /filename/foo.sml 2.1
        /filename/foo.sml 3.1
        /filename/foo.sml 4.1
    variable def2 /filename/foo.sml 5.1
        /filename/foo.sml 6.1
        /filename/foo.sml 7.1
    variable def3 /filename/foo.sml 8.1
    variable def4 /filename/foo.sml 9.1
        /filename/foo.sml 10.1
    variable def5 /filename/foo.sml 11.1

So while it's hard to know things on the granularity of a file, it's easy on
the granularity of an identifier.

My biggest concern with IDE tooling built around MLton right now is just how
long it takes. Since every re-loads the entire basis, even a simple
hello-world
program takes 6+ seconds on my low-spec laptop, and gets worse for longer
programs.

I know that MLton has an non-goal of separate compilation, but some form of
staged compilation or a server daemon that re-compiled specific files might
make it easy to work with with. For example, a daemon which watched for file
changes, selectively rebuilt those files, then re-output the def-use files.
Even if the granularity of the caching was on the order of
"Basis/non-Basis" I
imagine this would significantly increase responsiveness.

Just a few of my thoughts; I'm in favor of any better editor tooling for
SML!
Jake Z.