[Mono-dev] Incremental C# compiler

[Jonathan Gilbert]

t 06:48 PM 12/07/2006 +0200, Robert Jordan wrote:
>Jonathan Gilbert wrote:
>> One other possibility which should not be discounted out-of-hand, I think,
>> is the possibility of resurrecting the interpreter and bringing it
>> up-to-date. Certainly the hardest part of edit-and-continue of a running
>
>Edit-and-continue is best suited to debug/analyze/fix long running
>applications and/or apps with a long start-up time.
>The interpreter would kill all benefits of edit-and-continue.

I disagree with this. The majority of situations where I have seen
edit-and-continue employed (and have employed it myself) involve GUI
applications where the logic behind a short event handler is broken. See
below.

>Of course, for dudes who use to "massage a method until it works" (TM)
>the interpreter would be okay, but for those usage patterns
>I won't implement edit-and-continue ;-)

Like I said, I don't think the option should be discounted out-of-hand.
Consider the following:

1. The interpreter would only be used for the case where the method being
edited is *currently executing* on some thread.

2. The interpreter would be used to take over only that invocation of the
method. Thus, any lost speed benefits apply only to code within that
function for the duration of that call. Situations where a single method is
in a massively long loop and needs to be edited at runtime are more than
likely corner cases. Yes, I've written them before, but I've used
edit-and-continue far more often in GUI applications where the broken code
is, say, a button click handler that gets an item index from the wrong
place, or doesn't handle a possible null reference. It's certainly true
that it's no more than a convenience in this situation, but it's a
convenience that can greatly reduce development time, since you don't have
to bring the GUI up to the point of the bug every time you make a change to
the code.

3. Edit-and-continue has never been intended by anyone who has developed it
to be more than a stopgap measure, a means to test a fix quickly without
restarting the application. Once the fix has been verified to work, the
application will inevitably need to be rebuilt at some point. I don't think
I would feel comfortable using edit-and-continue on a long-running
application and then running it through to its finish on the "hacked" code.
I would feel even more uncomfortable running a network server on
edited-and-continued code.

4. The alternative to using an interpreter is very difficult to code. It
would probably take longer to get right than an entire functional
interpreter coded from scratch. In essence, it's a choice between having
the ability to edit methods that are running and not.

5. An implementation using an interpreter need not be permanent. It would
fill an important niche until a developer had the time & expertise to write
the code to munge the native execution context of the new JIT output.

6. An implementation using an interpreter would be inherently
platform-independent, whereas the "ideal" native version would, as far as I
can tell, tend to be platform-specific. Even if the native version were
implemented on some platforms, an interpreter-based implementation could be
a fallback for the alternative on platforms for which it had not yet been
written.

I also happen to think that it's a little bit arrogant to refuse to
implement a feature on the basis that some people would use it in a pattern
you disapprove of. It would be a little bit like refusing to implement
intellisense on the grounds that people only use it because they're too
lazy to memorize the framework.

Jonathan Gilbert