public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
From: Andrea Bernardini <andrebask@gmail.com>
To: Arvydas Silanskas <nma.arvydas.silanskas@gmail.com>
Cc: Per Bothner <per@bothner.com>, kawa mailing list <kawa@sourceware.org>
Subject: Re: First-class continuations in Kawa
Date: Sun, 8 Aug 2021 16:53:59 +0100	[thread overview]
Message-ID: <CAPFJfsvcW=WbdLZF6z2Zu3UpqNQeVAAxQraR9RfGiSJ9vuyv4Q@mail.gmail.com> (raw)
In-Reply-To: <CAPh7weBepqBVmKarG07NdphAsWfrbUVxxV=2YAONsTPFUH4EBg@mail.gmail.com>

Hi Arvydas,
As far as I remember we never took into account interaction of call/cc
outside of scheme code. The top level handler is added to the top level
ModuleExp when the scheme code is compiled. When you define a class I don't
think it's wrapped into a ModuleExp (I'm guessing here you are calling
call/cc inside a method in Foo).
A practical way to allow that could be to use a delimited continuation as
explained here:

https://andrebask.github.io/thesis/#other-control-operators-delimited-continuations

On Sun, 8 Aug 2021, 3:29 pm Arvydas Silanskas via Kawa, <kawa@sourceware.org>
wrote:

> I merged and got the original code mostly working (leaving optimization
> refactoring for later), but I ran into one major issue when creating
> benchmarks. It seems calling kawa from java gets conceptually broken if
> kawa classes are used directly. New call/cc requires top level handling
> loop, which gets bypassed if I instantiate and use directly, like
>
> ```
> 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?
> * 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.
> * 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?
>
>
> 2021-06-10, kt, 02:27 Per Bothner <per@bothner.com> rašė:
>
> >
> >
> > On 6/9/21 2:04 AM, Arvydas Silanskas wrote:
> > > Has anyone taken up on this? If not, I'll give it a try.
> >
> > As far as I know, nobody has stepped up, or is working in this.
> > Great if you want to step up.
> >
> > Do read my previous message carefully - though note that
> > 'usingSPSStyle' should be 'usingCPStyle'.
> > --
> >         --Per Bothner
> > per@bothner.com   http://per.bothner.com/
> >
>
>

  reply	other threads:[~2021-08-08 15:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-20  0:49 Duncan Mak
2018-01-20  6:47 ` Per Bothner
2018-01-20 16:07   ` Duncan Mak
2018-01-20 23:20     ` Andrea Bernardini
2018-02-21  0:21       ` Andrea Bernardini
2018-02-22  0:38         ` Duncan Mak
2021-05-01 16:15           ` Duncan Mak
2021-05-01 18:45             ` Arvydas Silanskas
2021-05-01 19:06               ` Sudarshan S Chawathe
2021-05-01 20:38                 ` Per Bothner
2021-06-09  9:04                   ` Arvydas Silanskas
2021-06-09 23:27                     ` Per Bothner
2021-08-08 14:29                       ` Arvydas Silanskas
2021-08-08 15:53                         ` Andrea Bernardini [this message]
2021-08-08 23:52                         ` Per Bothner
2021-08-09 19:41                           ` Per Bothner
2022-12-07 23:42                             ` Duncan Mak
2022-12-09 10:53                               ` Arvydas Silanskas

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='CAPFJfsvcW=WbdLZF6z2Zu3UpqNQeVAAxQraR9RfGiSJ9vuyv4Q@mail.gmail.com' \
    --to=andrebask@gmail.com \
    --cc=kawa@sourceware.org \
    --cc=nma.arvydas.silanskas@gmail.com \
    --cc=per@bothner.com \
    /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).