Re: Interactive SML use from Emacs, a question of approach

Matthew Fluet <[email protected]>
Newsgroups gmane.comp.lang.ml.mlton.user
Message-ID <CAMrhFL40xyRSP+JHaaS_FwD1jhi_LGAmKXgM8PdN2kbmdqtM1w@mail.gmail.com>
On Sat, Oct 12, 2013 at 12:55 PM, Christopher Cramer
<[email protected]> wrote:
> On Fri, Oct 11, 2013 at 12:45:04PM -0500, Grant Rettke wrote:
>> 1. Interactively send code to a REPL. Let the environment grow and
>> evolve. Restart the interpreter as needed.
>>
>> 2. Start a fresh REPL every time code is evaluated so that the
>> entirety of the system state is known and predictable.
>>
>> When I set up OCaml mode (tuareg), I did it like #2 and it worked
>> fine. Now I'm setting up SML mode, and I'm curious how other people do
>> their real development workflow in regards to REPL and development
>> management.
>
> MLton doesn't have an interactive REPL, so one could say #2 is the only
> way. But in practice most people seem to use SML/NJ or Poly/ML for
> development and then use MLton for the final build. MLton has very
> few deviations from the Definition, so you just need to make sure you
> don't use any SML/NJ or Poly/ML extensions.
>
> Personally, I use Vim and just use MLton to compile and nothing else. For
> large programs it can take a long time to compile everything, so what
> I do is type-check small, single files at a time (with -stop tc). There
> are two things that are necessary to make this work:
>
> 1. Split up the code into small (1000 lines or less ideally) files, with
> a simple external interface for each file, using opaque types. Otherwise
> the type errors will drive you crazy.
>
> 2. Create one MLB file (or more, see below) per SML source file. This
> encapsulates the dependencies and annotations for a given source file
> in one discrete place.

Another thing that would help, and that I'd eventually like to do, is
to have MLton do separate type-checking, but whole-program
compilation.  The fact that one almost invariably type checks the
Basis Library implementation (approximately 35.5K LoC spread over 365
files) even for the simplest of programs/libraries is a non-trivial
cost (over 2s on my amd64-linux desktop).  The elaboration of each
.mlb file could be written back to disk (say, in a ~/.mlton rooted
hierarchy) as the pair of an environment and annotated AST; loading a
.mlb file would then be as simple as checking the time stamps of the
.mlb file and referenced .mlb/.sml files against the serialized
elaboration, and if the serialized elaboration were up-to-date, then
load it directly.  I believe that the MLKit does something akin to
this.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.