🚀 go-pugleaf

In article <KERS.91May10092912@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
   Clearly redefining "sin" (Nico's later example) would be a Bad Thing. This just
   means that we need some way of annotating those names no longer available for
   redefinition - no big deal.

   Someone suggested that we needed ``better tools, not worse semantics'', to
   solve the problem of rebuilding after a change on which lots of things depend.
   Well, I can see the point in that, but it's a matter of opinion as to whether
   the semantics is ``worse''; and solving the problem by throwing CPU cycles at
   it seems to me to be the wrong approach.

"Better tools" does not mean "throwing CPU cycles at the problem".

You are proposing that I can say something like:

      redefine fun f x = ... ;

But I think this is a bad idea. I don't know about you, but I have a
hard time keeping track of the implications of redefinitions like
this.

Ultimately, what I expect of a good SML development environment is
that I edit some value "x" deep inside some structure, tell the system
that I'm through editing my sources, switch to the SML toplevel, and
find that the internal state of the SML system reflects the new state
of my sources, in particular the new value of "x". In order for this
to happen quickly enough, the system will have to generate commands
like "redefine" internally, but I never want to see them.

The "make" systems that float around are a start. Their major
shortcomings is that they don't infer dependencies automatically
(dependencies should be inferred, stored, and updated as I first load
and then modify my sources).  Also, they only work at a file level,
not a definition level.

It may also be possible to hack something up analogous to "make" that
relies on file modification dates, signatures for blocks of text
inside files, recording of information during load, etc., so that even
without a tight integration between editor and SML toplevel I may get
reasonable performance on recompilation. That is, when I tell the
system something like 'use "file.sml";', the system could use
knowledge of the previous contents of "file.sml" (and the contents and
modification dates of files "use"d by "file.sml") to infer what
"redefine" commands need to be issued in what sequence and come close
to minimal recompilation.

Again, I think making something like "redefine" visible to the user is
a bad idea. I certainly don't want to have to bother with it, and
implementors would just use it as an excuse not to have to come up with
decent development environments.

					Thomas.