From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105945 invoked by alias); 5 Apr 2015 20:49:03 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 105921 invoked by uid 89); 5 Apr 2015 20:49:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: st11p02mm-asmtp002.mac.com Received: from st11p02mm-asmtpout002.mac.com (HELO st11p02mm-asmtp002.mac.com) (17.172.220.237) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 05 Apr 2015 20:49:01 +0000 Received: from [192.168.1.75] (99-3-56-155.lightspeed.fyvlar.sbcglobal.net [99.3.56.155]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NMC005T7PTLCQ10@st11p02mm-asmtp002.mac.com> for kawa@sourceware.org; Sun, 05 Apr 2015 20:48:59 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-05_03:2015-04-03,2015-04-05,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504050201 Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Redefinition/re-loading [was: kawa paid support] From: mikel evins In-reply-to: <55219CE9.3080207@bothner.com> Date: Sun, 05 Apr 2015 20:49:00 -0000 Cc: mikel evins , Kawa Mailing List Content-transfer-encoding: quoted-printable Message-id: <531745C2-2F08-4E41-A9F9-329E28B3417D@me.com> References: <5519D688.7080704@bothner.com> <5520C199.9010705@gmail.com> <5520DB6D.6060208@bothner.com> <20755B3D-7B83-4772-A18C-E62901015DAD@me.com> <55219CE9.3080207@bothner.com> To: Per Bothner X-IsSubscribed: yes X-SW-Source: 2015-q2/txt/msg00013.txt.bz2 > On Apr 5, 2015, at 3:36 PM, Per Bothner wrote: >=20 >=20 >=20 > 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, ... >=20 > Have you tried using --no-inline ? This should reduce the confusion > on redefinition. Using --no-inline could cause subtle changes in behavio= r, > 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 func= tion. 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 bette= r. Why worse? Because if such problems are still common, but uncommon enoug= h that I don't immediately realize what's happening, then I might spend mor= e 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 interacti= ve-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 indi= rectly > 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.=20 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 cl= ass, existing instances are updated as-needed to reflect the new class defi= nition, but I'm not claiming that's an easy thing to support. CLOS has a wh= ole 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.ed= u/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_7-2.html), and I'm not go= ing to claim it's reasonable to expect you to add all of that.