From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christine Lemmer-Webber Newsgroups: gmane.lisp.guile.devel Subject: Re: Is it possible to get ijp's js branch working anymore? Date: Mon, 11 Oct 2021 23:48:12 -0400 Message-ID: <87o87u7un6.fsf@dustycloud.org> References: <87a6p1l47j.fsf@dustycloud.org> <87r1idjokk.fsf@dustycloud.org> <87bl9hjo1e.fsf@dustycloud.org> <87y270conf.fsf@dustycloud.org> <87czocce7x.fsf@web.de> <87bl3v9fwk.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36182"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.6; emacs 27.2 Cc: guile-devel@gnu.org, Ian Price To: "Dr. Arne Babenhauserheide" , Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Oct 12 06:08:56 2021 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ma960-0009D7-9P for guile-devel@m.gmane-mx.org; Tue, 12 Oct 2021 06:08:56 +0200 Original-Received: from localhost ([::1]:36582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ma95y-0007za-Rd for guile-devel@m.gmane-mx.org; Tue, 12 Oct 2021 00:08:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ma959-0007w2-6Y for guile-devel@gnu.org; Tue, 12 Oct 2021 00:08:03 -0400 Original-Received: from dustycloud.org ([50.116.34.160]:38568) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ma956-0004dH-UT for guile-devel@gnu.org; Tue, 12 Oct 2021 00:08:02 -0400 Original-Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 6458526630; Tue, 12 Oct 2021 00:07:58 -0400 (EDT) In-reply-to: <87bl3v9fwk.fsf@dustycloud.org> Received-SPF: pass client-ip=50.116.34.160; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:20912 Archived-At: Christine Lemmer-Webber writes: > I've moved this thread from guile-user to guile-devel. > > "Dr. Arne Babenhauserheide" writes: > >> Christine Lemmer-Webber writes: >> >>> I have pushed one more merge with master to the compile-to-js-merge >>> branch. I've taken the bold move of pushing this to origin... I think >>> it's a good idea to try to get this in, so it's worth it not just >>> sitting in my own personal repo. >> >> wow =E2=80=94 thank you! >> >> Is there a short example on how to use this branch for the features that >> already work? >> >> Best wishes, >> Arne > > ijp's email, at the start of this thread (see 2017-08-28 in the > guile-user mail archive) explains everything better than I could. > However, the branch does not really work. I'm worried it might not be > able to, see below. > > I've actually made it past the last hurdle I mentioned in my thread; > turns out I was closer on track when I last tried to merge this than in > the efforts I made within the last week. And so I'm now at the point > where I think I'm dealing with the real merge issues. Wingo, I've cc'ed > you... I think you're our main hope here. > > Here's the problem: CPS changed a lot since ijp wrote this... and it may > have gotten advanced enough that merging has become very difficult. > The problem started out with records that look like so: > > # > > There are two weird things here: > > - $primcall used to only have args that were a list; now there are some > weird ones with cons cells, like 'allocate-words/immediate. I see > that compile-bytecode.scm has grown to pattern match against a > significant number of these. So, ok, we have to do the same in > compile-js.scm. > > - Except that wait a minute... 'allocate-words/immediate ?! > This sounds *really* low-level. Wait, it *is* really low-level! > Right now ijp's branch had a runtime.js branch which translated > a bunch of these primitives, and that could be done quasi-reasonably, > but allocate-words/immediate.... what the heck do we do with that > in javascript?! > > The commit where things seem to have gotten low-level in CPS land is > 9f98b4a5b1067b177c700d27abf4ed477f013951. Here's the big relevant > change: > > #+BEGIN_SRC diff > diff --git a/module/language/cps/closure-conversion.scm b/module/language= /cps/closure-conversion.scm > index 4f9296397..746e5cebe 100644 > --- a/module/language/cps/closure-conversion.scm > +++ b/module/language/cps/closure-conversion.scm > @@ -19,9 +19,8 @@ > ;;; Commentary: > ;;; > ;;; This pass converts a CPS term in such a way that no function has any > -;;; free variables. Instead, closures are built explicitly with > -;;; make-closure primcalls, and free variables are referenced through > -;;; the closure. > +;;; free variables. Instead, closures are built explicitly as heap > +;;; objects, and free variables are referenced through the closure. > ;;; > ;;; Closure conversion also removes any $rec expressions that > ;;; contification did not handle. See (language cps) for a further > @@ -520,10 +519,36 @@ term." > (define (allocate-closure cps k src label known? nfree) > "Allocate a new closure, and pass it to $var{k}." > (match (vector known? nfree) > + (#(#f 0) > + ;; The call sites cannot be enumerated, but the closure has no > + ;; identity; statically allocate it. > + (with-cps cps > + (build-term ($continue k src ($closure label 0))))) > (#(#f nfree) > ;; The call sites cannot be enumerated; allocate a closure. > (with-cps cps > - (build-term ($continue k src ($closure label nfree))))) > + (letv closure tag code) > + (letk k* ($kargs () () > + ($continue k src ($values (closure))))) > + (letk kinit ($kargs ('code) (code) > + ($continue k* src > + ($primcall 'word-set!/immediate '(closure . 1) > + (closure code))))) > + (letk kcode ($kargs () () > + ($continue kinit src ($code label)))) > + (letk ktag1 > + ($kargs ('tag) (tag) > + ($continue kcode src > + ($primcall 'word-set!/immediate '(closure . 0) > + (closure tag))))) > + (letk ktag0 > + ($kargs ('closure) (closure) > + ($continue ktag1 src > + ($primcall 'load-u64 (+ %tc7-program (ash nfree 16)= ) ())))) > + (build-term > + ($continue ktag0 src > + ($primcall 'allocate-words/immediate `(closure . ,(+ nfre= e 2)) > + ()))))) > (#(#t 2) > ;; Well-known closure with two free variables; the closure is a > ;; pair. > #+END_SRC > > I'm not really sure what to do. I don't mean to complain; I, along with > everyone here, has benefitted from Wingo's constant tweaking of this > stuff, making it all more and more efficient. But can it still be > compatible with ijp's vision of javascript emerging the cps layer? > > Here's my gut sense though: I wonder if CPS can be broken into phases, > one that does these smarter low-level memory tweaks, and one that > doesn't, so that ijp's lovely branch has a chance of being merged. > > Or maybe there's a more obvious path? > > What to do?! Wingo, we need your help! > > - Christine Some further thinking for the moment... I see three possible paths: - Actually separate out CPS into two languages: high-cps, and low-cps. high-cps is the CPS version pre memory fiddling stuff, something possible to transform into js, for instance. - Wingo mentioned this "wip-tailify" branch which I really haven't looked at but sounds like it's actually covering this path: https://lists.gnu.org/archive/html/guile-devel/2021-06/msg00005.html We decide okay, you know what, that's the direction that ijp's stuff should be put on top of. Let's do that. (Or, maybe the energy moves towards WASM instead, though it might be nicer if it was in-addition-to, but hack time does tend to be limited.) - A goofy middle ground is to actually just compile from tree-il to js-il instead (and then to javascript... so this could still use some of the work from ijp's branch). This could probably work, but only certain scheme programs could be converted: multiple value return will turn out to not be possible, for instance. (I guess it won't be in any generated-from-scheme code that is exposed to javascript anyway...?) No idea what's the right path. The middle one does sound promising though. I haven't looked at the branch much yet...