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: full moon, vm status update Date: Fri, 31 Oct 2008 18:54:41 +0100 Message-ID: References: <87y70owdeq.fsf@gnu.org> <49dd78620810180326i636e9275v7eba6a0ada606e44@mail.gmail.com> <49dd78620810271651u3bed4b50jeecfc2b33d85a748@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1225477624 26570 80.91.229.12 (31 Oct 2008 18:27:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2008 18:27:04 +0000 (UTC) Cc: =?utf-8?Q?Ludovic_Court=C3=A8s?= , guile-devel@gnu.org To: "Neil Jerram" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Oct 31 19:28:04 2008 connect(): Connection refused Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kvyiw-0007jq-Dk for guile-devel@m.gmane.org; Fri, 31 Oct 2008 19:27:54 +0100 Original-Received: from localhost ([127.0.0.1]:36327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kvyhp-00085U-T8 for guile-devel@m.gmane.org; Fri, 31 Oct 2008 14:26:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kvyhj-00085A-3Z for guile-devel@gnu.org; Fri, 31 Oct 2008 14:26:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kvyhh-00084t-Ez for guile-devel@gnu.org; Fri, 31 Oct 2008 14:26:38 -0400 Original-Received: from [199.232.76.173] (port=59294 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kvyhh-00084l-95 for guile-devel@gnu.org; Fri, 31 Oct 2008 14:26:37 -0400 Original-Received: from a-sasl-fastnet.sasl.smtp.pobox.com ([207.106.133.19]:43328 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvyhY-0002yH-PL; Fri, 31 Oct 2008 14:26:29 -0400 Original-Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 86E4377DC2; Fri, 31 Oct 2008 14:26:16 -0400 (EDT) Original-Received: from unquote (232.Red-81-38-182.dynamicIP.rima-tde.net [81.38.182.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id D946577DBD; Fri, 31 Oct 2008 14:26:06 -0400 (EDT) In-Reply-To: <49dd78620810271651u3bed4b50jeecfc2b33d85a748@mail.gmail.com> (Neil Jerram's message of "Mon, 27 Oct 2008 23:51:44 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Pobox-Relay-ID: 67CD846E-A779-11DD-B819-9CEDC82D7133-02397024!a-sasl-fastnet.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7798 Archived-At: Hi Neil, On Tue 28 Oct 2008 00:51, "Neil Jerram" writes: > It's not rocket science, and you probably guessed at that solution > already - but I think it really is the _right_ fix, because > > - the principle of the elisp integration is that there is a new value > #nil, which acts as EOL in list contexts, and as #f in boolean > contexts > > - as one example of this, the non-VM apply accepts and handles a list > whose tail is #nil > > - therefore the VM apply should too. > > What do you think? So, I'm really happy that you're hacking on this! I think there are better ways of supporting multiple languages than the approach taken historically by Guile, and that taken by this patch. I do not think the interpreter / subr division is appropriate for a multilingual system. To me, the division should be: * The evaluator / interpreter, that deals in Scheme; * A layered compiler, with different top-level layers for e.g. Guile, R6RS, Elisp, etc * A VM, with generic opcodes and opcodes specific to the languages that target the VM * A library of procedures written in C, where each procedure is related to /one/ language, Scheme in the case of most procedures. So, the best option would be to have /a separate elisp compiler/. You already have this, sortof. But in the specific context of apply, I would have "apply" be a different operator in the elisp case, supported by an elisp-specific opcode that deals with nil. (Alternately, you could redefine `apply' in Scheme, for the elisp case: (define (elisp-apply f . lists) (apply apply f (frobate lists)))) Granted, we have ideals, and we have tradeoffs, and writing an elisp compiler. (Then again, maybe not that bad.) If I have to add what I consider to be a hack to the `apply' case in order to keep you hacking on the VM, then the tradeoff is worth it to me. But at some point I think you should indulge your secret desire of writing a compiler! ;-) What do you think of all this? Cheers, Andy -- http://wingolog.org/