From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) by sourceware.org (Postfix) with ESMTPS id 24EEE385DC06 for ; Sun, 8 Aug 2021 23:53:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24EEE385DC06 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bothner.com Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1mCsbE-000513-Ea; Mon, 09 Aug 2021 01:53:00 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1mCsb5-0005oy-Q1; Mon, 09 Aug 2021 01:52:52 +0200 Subject: Re: First-class continuations in Kawa To: Arvydas Silanskas Cc: kawa mailing list References: <23585.1619896007@localhost> <11feb74b-49fa-3fbd-213d-7d939dccfb1a@bothner.com> <666b9a7d-156b-0ee7-e1a1-9409cf0d376f@bothner.com> From: Per Bothner Message-ID: Date: Sun, 8 Aug 2021 16:52:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 23:53:04 -0000 On 8/8/21 7:29 AM, Arvydas Silanskas wrote: > I merged and got the original code mostly working (leaving optimization refactoring for later), Cool. > var foo = (FooInterface) Class.forName("Foo").newInstance(); > foo.bar(); > ``` > > where FooInterface is an interface written in java, and Foo is a class created by `define-simple-class` on kawa side which specifies said interface as one of its supers. > > * Am I using the recommended approach for java -> kawa interaction? For the simple case. But clearly it might not work in general. Does what you're trying to work when Foo is compiled with --full-tailcalls ? The latter also makes use of a top-level handling loop, but there are automatic "bridges" between the two styles of functions (see CallContext.runUntilDone). Based on a trivial test, a bar method in a Foo class under --full-tailcall just becomes a plain Java method (without tail-call support). > * If yes to the first question, do we strongly care that this type of calling gets broken as a compromise? After all the (optionally enabled, by default disabled) full continuations will weaken interop anyway, so maybe this is not worth trying to save. I'm not certain what a fix would be, maybe some sort of custom equivalent to Class.forName, which would return a proxied class with the handling loop attached to the methods. I think its ok to require people to write wrapper code in Scheme when generating "simple" classes. > * The points about using CPStyle / CALL_WITH_TAILCALLS from what I can understand are purely regarding optimizations, right? Or do you think that refactored code using those approaches would also solve the problem above? Implementing CPStyle / CALL_WITH_CONTINUATIONS is mostly performance. However, since CALL_WITH_CONTINUATIONS is sort of an extension of CALL_WITH_TAILCALLS, I think the whole system would be better integrated. Specifically having a single CallContext.runUntilDone with that handles both continuations and tail-calls would be preferable. (I think I haven't looked much at this code in a while.) -- --Per Bothner per@bothner.com http://per.bothner.com/