From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Questions about the compiler et al Date: Sun, 08 Jan 2012 01:03:52 +0100 Message-ID: <8739brf4bb.fsf@pobox.com> References: <87ehveeldv.fsf@netris.org> <87ehvenqg7.fsf@pobox.com> <8762gqdq1y.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1325981049 11754 80.91.229.12 (8 Jan 2012 00:04:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 8 Jan 2012 00:04:09 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jan 08 01:04:04 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RjgF1-0004E5-Sc for guile-devel@m.gmane.org; Sun, 08 Jan 2012 01:04:04 +0100 Original-Received: from localhost ([::1]:42068 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjgF1-00074r-Fd for guile-devel@m.gmane.org; Sat, 07 Jan 2012 19:04:03 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:46890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjgEy-00074b-8G for guile-devel@gnu.org; Sat, 07 Jan 2012 19:04:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjgEw-0003qS-Eb for guile-devel@gnu.org; Sat, 07 Jan 2012 19:04:00 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:38590 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjgEw-0003qM-7w for guile-devel@gnu.org; Sat, 07 Jan 2012 19:03:58 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AF32686FC; Sat, 7 Jan 2012 19:03:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=nxVw0RvdzoSL0P2Z2v1/c42bEJQ=; b=gd/BKe IQLkMo5xpw6WnlOHNPrFrKeC/qAclSqXZ2/xfZocNSgakqY5VRa0+nRZtX6WcC6c YSD6P6TWF5dkhnYiuBaAWikRL4h810xKxCJ/7z3xBcguX+k0hVJa+NIaUDM+Veof U7XdNFSXtVwrb4SmFDpGQVl+qY8Afx4CbMPZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=uVhUEtEtNRlk5qbdEB8GUrTpIgvn1s4U wmByJWUlIQ25uk/3GRMD4DJAvU6EUe1exKcM3p0ZOA85m8ShEiUf8tBXzVU6bdD1 jNlZP88OLMN4njCL0vRG1zwcNrxL5p8yZNo9fAG3aR2yzaaefgyezjcOsexzt3Wq Bwx7zKtQuV4= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A7EF486FB; Sat, 7 Jan 2012 19:03:57 -0500 (EST) Original-Received: from badger (unknown [90.164.198.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id E27BD86F9; Sat, 7 Jan 2012 19:03:56 -0500 (EST) In-Reply-To: <8762gqdq1y.fsf@netris.org> (Mark H. Weaver's message of "Thu, 05 Jan 2012 12:20:25 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: 427154AE-398C-11E1-9B93-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13429 Archived-At: Hi Mark, On Thu 05 Jan 2012 18:20, Mark H Weaver writes: > Andy Wingo writes: >>> * Is there any way to embed references to non-serializable objects in >>> compiled code? >> >> No. Can you give an example of when you would want this? > > My more complex `the-environment' patch fully supports captured local > syntax definitions in the evaluator, and would also do so for the > compiler if not for this limitation. Code generated by > (the-environment) needs to embed references to the captured local syntax > transformers. I can imagine some hacks to work around this limitation, > but they're not nice. > > My more complex patch adds support for attaching an objtable and > free-vars to the compiler environment for use by `objcode->value', and I > successfully used this to attach the free-vars to the compiled closure. > > I also did some work on providing a compiler option for > `compile-assembly' to attach the objtable to the target-environment > instead of serializing it as code, but didn't finish that job. I still > think it might be useful. Any suggestions (or objections)? Hummmm. Yeah, maybe. I guess there is room for this -- see for example module/language/objcode/spec.scm:76. It would be nice to unify the representations of environments between the compiler and the decompiler. Tricky, though. > Furthermore, I'd suggest that _not_ serializing the objtable should be > the default behavior, and that `compile-file' should instead add a > compiler option to force objtable serialization. The rationale is that > I expect most uses of `compile' from within user code to compile to > `value' anyway, and forcing serialization needlessly adds overhead, and > more importantly, limitations on what might be found within (quote _) > forms of generated code. What do you think? Makes sense to me. >>> * Should we move to support compiler environments that are not simply >>> modules? >> >> Perhaps. It used to be the case that things were different: see >> f95f82f8e183f2744740bdc950dba9c856e09094. But it turned out that having >> environments that could only be interpreted by specific languages made >> it difficult to have a generic language tower, so I changed them all to >> have one representation, namely, as modules. > > I agree that a single extensible representation (like alists) for all > languages is probably best, but I think it's important to make this > representation distinct from modules ASAP, before the assumption that > they're modules becomes too deeply entrenched. > > Although it's easy enough for compilers to accept a new representation > while still accepting modules, I'm more concerned about their return > values. What happens if a bunch of external code is written that > assumes compilers will always return modules as environments? > > There's a danger that we might become unable to use environments for > anything else without breaking compatibility. ACK. Was it the right thing, in the end, to have environments specific to the language? Maybe so; the Scheme compiler shouldn't know anything about object tables (or elisp DECLAIM settings), and each compiler knows its source and target language, so that it can consume and produce environments of the appropriate type... If I can strain my memory enough, I think that the reason that I made the change was so that I could document the interfaces in some way that made coherent sense. If you are able to envision a change that can be explained coherently, then let's look at it. >>> * Do modules created by (make-fresh-user-module) get garbage collected? >> >> In theory, yes. > > Is this practical? Do these fresh modules have names? They get names only on demand; see boot-9.scm:2405. I think that once they have names, there are no longer collectable. >>> * Why is `procedure-environment' still documented as "Very deprecated"? >>> Is it still available at all? >> >> It is removed in master. > > I cannot find its implementation anywhere in stable-2.0, but it is still > documented. I guess it should be removed from the doc, or the doc > should at least mention that it has already been removed. Or no? Probably removed from the documentation, I would think. Thanks for taking a look at this piece of code! Cheers, Andy -- http://wingolog.org/