Re: Redefinition/re-loading [was: kawa paid support]

[mikel evins <mevins at me dot com>]

> On Apr 5, 2015, at 3:36 PM, Per Bothner <per@bothner.com> wrote:
> 
> 
> 
> On 04/05/2015 01:02 PM, mikel evins wrote:
>> Lack of redefinition
>> support kind of kills the Lispiness of working with Kawa. Because any
>> given reload or eval can cause the JVM to become confused, ...
> 
> Have you tried using --no-inline ?  This should reduce the confusion
> on redefinition.  Using --no-inline could cause subtle changes in behavior,
> and of course it does hurt performance.  In any case, it's only a partial
> solution, since if you change the type of a function you want to re-do
> the type inference and date flow of code that depends on the changed function.

I haven't tried it, on the possibly-wrong theory that making the time gaps larger between problems occurring would make things worse rather than better. Why worse? Because if such problems are still common, but uncommon enough that I don't immediately realize what's happening, then I might spend more unproductive time trying to solve nonexistent issues.

That's all purely speculative, though, since I haven't actually tried it. I should and I will. I don't think performance is an issue for the interactive-development case, anyway.

> It would be useful to have a design document for what *should* happen
> on re-definition/re-loading.  Replacing a function with an updated one is
> relatively easy, and maybe that should be the priority.  But what about
> top-level expressions and variable definitions?  When should they get re-evaluated?
> And what about changing class definitions - if there are existing objects
> of the "old" class in the heap?  If you only support changing the body of
> method (and not its parameter or return types), and don't support changing
> fields, we can support that using indirection: Compile the method to indirectly
> call a function that we can update.

Yeah, you're right; there should be a design document.

My point of reference for interactive development is basically Common Lisp environments, but Common Lisp has well defined semantics for redefinition, and special forms (EVAL-WHEN) for controlling what gets evaluated when.

Yeah, I'd want a function redefinition to replace the defined function. I'd want toplevel expressions to get redefined, and toplevel variables, too. 

I would *want* classes to be redefined as well, but, as you mention, there's a can of worms there. In a Common Lisp environment when you redefine a class, existing instances are updated as-needed to reflect the new class definition, but I'm not claiming that's an easy thing to support. CLOS has a whole suite of features designed specifically to support that (see section 7.2 of the spec, "Changing the class of an instance," or http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_7-2.html), and I'm not going to claim it's reasonable to expect you to add all of that.