Re: [MLton] ML hack evening ideas

[Matthew F. <mat...@gm...>]

On Mon, Jul 10, 2017 at 12:41 AM, Jake Zimmerman <ja...@zi...> wrote:
> 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.

Right, I wasn't so much suggesting making changes to the def-use
information emitted by MLton, but rather use that editor agnostic
information in a backend to a more standard emacs package for
navigating source code.

>> 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.

True, once you have the def-use information and are using it, then it
is relatively easy to track down defs from uses.  But, for novices,
sometimes this lack of context is a complaint.

> 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.

Yes, some kind of separate type checking would be very nice (but not
an evening hack project!).