public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
From: Per Bothner <per@bothner.com>
To: kawa@sourceware.org
Subject: Re: JavaFX unexpected warning
Date: Thu, 01 Nov 2018 15:08:00 -0000	[thread overview]
Message-ID: <92142ecb-f7f8-92ad-0d83-cc88eee1242e@bothner.com> (raw)
In-Reply-To: <0ce1028e9d7a71afbb5f7abc57e2b707.squirrel@mail.theptrgroup.com>

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/

  reply	other threads:[~2018-11-01 15:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01 13:41 Jamison Hope
2018-11-01 15:08 ` Per Bothner [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-10-31  9:31 Arie van Wingerden
2018-10-31  9:49 ` Sudarshan S Chawathe
2018-10-31 11:17   ` Arie van Wingerden
2018-10-31 17:23     ` Per Bothner
2018-11-01  5:32       ` Per Bothner
2018-11-01 10:21         ` Arie van Wingerden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=92142ecb-f7f8-92ad-0d83-cc88eee1242e@bothner.com \
    --to=per@bothner.com \
    --cc=kawa@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).