Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!ai-lab!life!tmb From: tmb@ai.mit.edu (Thomas M. Breuel) Newsgroups: comp.lang.functional Subject: Re: Help needed with behaviour of SML (its interactive system) Message-ID: Date: 6 May 91 01:54:07 GMT References: <9104262016.AA28063@enuxha.eas.asu.edu> <20644@ogicse.ogi.edu> <3224@opal.cs.tu-berlin.de> Sender: news@ai.mit.edu Followup-To: comp.lang.functional Organization: MIT Artificial Intelligence Lab Lines: 31 In-reply-to: wg@opal.cs.tu-berlin.de's message of 4 May 91 21:36:39 GMT [lots of articles complaining about the fact that you can't change top-level bindings in ML] For example, wg@opal.cs.tu-berlin.de writes: Or is there someone working professional with SML who takes advantage of the interactive system? Personal (relatively little) experiences with the SML environment is that one soon writes batch files to work around it. I use SML interactively: source files in one (Emacs) window, SML in another window. I usually have one source file in which I write and debug new functions, and, eventually, they get wrapped up into a new module. Working this way, I usually only have to recompile the function I'm currently debugging (C-c C-c). If I have to fix older functions, I simply recompile the whole file (C-c C-u), or recompile them in the right order. This is not very different from CommonLisp development. I like the behavior of the SML top-level. I think any attempt at allowing the user to change the binding, or, worse yet, type of an already existing binding, would introduce lots of complications and make the top-level much harder to understand. It would also keep the compiler from making lots of optimizations that it currently can make. If recompilation speed really turns out to be an issue, an implementation of SML could, within the current language semantics, record dependencies during the first compilation and avoid recompilation of unchanged and independent values even if you just told it "compile everything". Better compilers, not worse semantics, are the answer to this issue.