Re: [MLton] ML hack evening ideas

--===============8964058832845179187==
Content-Type: multipart/alternative; boundary="f403045c5a42d61bca0553ef33b8"

--f403045c5a42d61bca0553ef33b8
Content-Type: text/plain; charset="UTF-8"

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.

--f403045c5a42d61bca0553ef33b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>While we&#39;re on the topic of editor/IDE support fo=
r SML:</div><div><br></div><div>&gt; Additional IDE (esp. Emacs) support.=
=C2=A0 For example, MLton has a</div><div>&gt; &#39;def-use&#39; mode for e=
macs (<a href=3D"http://mlton.org/EmacsDefUseMode">http://mlton.org/EmacsDe=
fUseMode</a>), which I</div><div>&gt; use quite a bit, but I wonder if it w=
ouldn&#39;t be better to integrate</div><div>&gt; with one of the general-p=
urpose emacs packages for that purpose (e.g.,</div><div>&gt; ctags, xref).=
=C2=A0 Similarly, I&#39;d love to get some kind of completion</div><div>&gt=
; support, presumably using the emacs company-mode package.</div><div><br><=
/div><div>I actually recently ported the Emacs def-use mode to a Vim plugin=
</div><div>(<a href=3D"https://github.com/jez/vim-better-sml">https://githu=
b.com/jez/vim-better-sml</a>). One thing that&#39;s nice about the way</div=
><div>MLton works now is that the def-use information is editor agnostic: i=
t just</div><div>dumps the information in an easy-to-consume format. This m=
eans integrating with</div><div>other editors is straightforward.</div><div=
><br></div><div>&gt; One issue with IDE support for SML is that it is often=
 difficult</div><div>&gt; (if not impossible) to know the context in which =
a .sml file is meant</div><div>&gt; to be used; it is implicit in the conta=
ining .mlb or .cm file.=C2=A0 So,</div><div>&gt; unlike most languages, whe=
re upon encountering an identifier that is</div><div>&gt; not bound in the =
file, one jumps to the top of the file to look at the</div><div>&gt; #impor=
t or include directives, one needs to do more work with SML</div><div>&gt; =
files.</div><div><br></div><div>I&#39;d argue that at least the output of t=
he def-use information makes this point</div><div>not so important. For tho=
se unfamiliar, here&#39;s a sampling from a def-use file:</div><div><br></d=
iv><div><div>=C2=A0 =C2=A0 variable def1 /filename/foo.sml 1.1</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /filename/foo.sml 2.1</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 /filename/foo.sml 3.1</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=
filename/foo.sml 4.1</div><div>=C2=A0 =C2=A0 variable def2 /filename/foo.sm=
l 5.1</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /filename/foo.sml 6.1</div><div=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /filename/foo.sml 7.1</div><div>=C2=A0 =C2=A0 =
variable def3 /filename/foo.sml 8.1</div><div>=C2=A0 =C2=A0 variable def4 /=
filename/foo.sml 9.1</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /filename/foo.sm=
l 10.1</div><div>=C2=A0 =C2=A0 variable def5 /filename/foo.sml 11.1</div></=
div><div><br></div><div>So while it&#39;s hard to know things on the granul=
arity of a file, it&#39;s easy on</div><div>the granularity of an identifie=
r.</div><div><br></div><div>My biggest concern with IDE tooling built aroun=
d MLton right now is just how</div><div>long it takes. Since every re-loads=
 the entire basis, even a simple hello-world</div><div>program takes 6+ sec=
onds on my low-spec laptop, and gets worse for longer</div><div>programs.</=
div><div><br></div><div>I know that MLton has an non-goal of separate compi=
lation, but some form of</div><div>staged compilation or a server daemon th=
at re-compiled specific files might</div><div>make it easy to work with wit=
h. For example, a daemon which watched for file</div><div>changes, selectiv=
ely rebuilt those files, then re-output the def-use files.</div><div>Even i=
f the granularity of the caching was on the order of &quot;Basis/non-Basis&=
quot; I</div><div>imagine this would significantly increase responsiveness.=
</div><div><br></div><div>Just a few of my thoughts; I&#39;m in favor of an=
y better editor tooling for SML!</div><div>Jake Z.</div><div><br></div></di=
v>

--f403045c5a42d61bca0553ef33b8--


--===============8964058832845179187==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============8964058832845179187==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel

--===============8964058832845179187==--