From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32087 invoked by alias); 1 Nov 2018 15:08:17 -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 32003 invoked by uid 89); 1 Nov 2018 15:08:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: aibo.runbox.com Received: from aibo.runbox.com (HELO aibo.runbox.com) (91.220.196.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Nov 2018 15:08:15 +0000 Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1gIEZw-0006Sr-7D for kawa@sourceware.org; Thu, 01 Nov 2018 16:08:12 +0100 Received: by mailfront12.runbox.com with esmtpsa (uid:757155 ) (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) id 1gIEYK-0006SS-84 for kawa@sourceware.org; Thu, 01 Nov 2018 16:06:33 +0100 Subject: Re: JavaFX unexpected warning To: kawa@sourceware.org References: <0ce1028e9d7a71afbb5f7abc57e2b707.squirrel@mail.theptrgroup.com> From: Per Bothner Message-ID: <92142ecb-f7f8-92ad-0d83-cc88eee1242e@bothner.com> Date: Thu, 01 Nov 2018 15:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0ce1028e9d7a71afbb5f7abc57e2b707.squirrel@mail.theptrgroup.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00023.txt.bz2 On 11/1/18 6:41 AM, Jamison Hope wrote: > Is there anything in the (existing) letrec implementation that could help > here? It seems like you’re describing transforming the two define-constant > calls into basically a letrec except without actually introducing a new > scope. They key trick is splitting object creating into two separate parts: Allocating the object, and initializing the properties of the object. And then assigning each variable with the allocated object(s) before doing further initialization. Letrec won't do that. However, letrec would do what we needed if we used promises (https://www.gnu.org/software/kawa/Lazy-evaluation.html#Blank-promises). In that cases we initialize each variable with a blank promise as a place-holder. Then we evaluate each initialization, and bind the promise with the result. Any recursive reference will grab the unforced promise, which does what we need - as long as the promise isn't forced. And that is the problem, since if you need to coerce a field value to a specific type you may hang. Plus whoever uses the created object (such as a GUI library) has to know how to deal with promises. The JavaFX API does support a kind a promises, since the various components are "properties" that can be bound. The old JavaFX 1.0 language handled these dependencies automatically, but it was abandoned because of complexity and performance concerns (plus lack of take-up - plus Oracle taking over ...). If JavaFX had become more popular it might be worth figuring out a good way to express JavaFX bindings and constraints wih Kawa compiler support, but JavaFX never took off and is basically in maintenance mode. I'm interested in supporting "logic programming" in some way, which we can think of as more complicated networks of objects with constraints. (This might be more suited for the KaShell language (http://kashell.org) than the Kawa-Scheme language.) The trick is not adding overhead unless you ask for it! > Remind me, can you (define-constant x …) with x already a bound > identifier? You can define-constant in an inner scope. The '!' operator is like define-constant, plus pattern-matching, plus complaining if a declaration in an inner scope hides one in an outer scope (like Java). > Is there a danger that this reordering might capture the wrong > list2 when building list1? I’m thinking along the lines of letrec vs let*. Without the ordering you would get #!null instead of list2 - because list2 hasn't been assigned yet. > Would this optimization apply to any other kinds of variable binding, or > just adjacent define-constant expressions? As designed it would only apply to define-constant and the '!' operator. We could generalize it to variables that are only assigned to once. However, we are changing the semantics (say if the "raw allocation function" is a constructor method with side-effects), so I think it makes sense to restrict this to explicit "constant" variables. -- --Per Bothner per@bothner.com http://per.bothner.com/