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: towards a more unified procedure application mechanism Date: Sun, 30 Aug 2009 17:45:56 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1251647258 25488 80.91.229.12 (30 Aug 2009 15:47:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2009 15:47:38 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Aug 30 17:47:31 2009 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 1Mhmcp-0007oi-B7 for guile-devel@m.gmane.org; Sun, 30 Aug 2009 17:47:31 +0200 Original-Received: from localhost ([127.0.0.1]:51922 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mhmcn-000861-Hb for guile-devel@m.gmane.org; Sun, 30 Aug 2009 11:47:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mhmch-00085h-Rx for guile-devel@gnu.org; Sun, 30 Aug 2009 11:47:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mhmcd-00084v-GW for guile-devel@gnu.org; Sun, 30 Aug 2009 11:47:19 -0400 Original-Received: from [199.232.76.173] (port=34571 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mhmcd-00084p-7I for guile-devel@gnu.org; Sun, 30 Aug 2009 11:47:15 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62]:63863 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mhmcc-0005lr-AO for guile-devel@gnu.org; Sun, 30 Aug 2009 11:47:14 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 611A33D606 for ; Sun, 30 Aug 2009 11:47:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=nEnnB0/k5Q/HVOexqJjDatWA5YE=; b=XIUbdm a7pa2ZqYee5pgIBImPTy+rF9TdK47hmw2ZeLY3RXs/F7CCF8rfXa+jOpzikG/7ap xNlXmAhJ0M/rKr1SJGPOyM5v9xXE4WNSQlXYp6Hs0kegDPtI2oF2+djgZhiz7V9A CxkHxMgxq2xU15GtVOCzPnJwNVlfH4345N4+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=oeJwkv5ljSwgNDCDf2p16FzxvMLtYybR IggBqNPY17tvJDY5BaL5ejZCXaMTxYCEu+vq8S8upkohmF+XUlxacmneevmhQg9+ MjkdV0pMJw6VT0lh53czp3zPkOv6dgbpZx5ukhkihe12tCiFIbZ+5gk3f4wcleLm 8wCj8BP2Nw0= 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 5EBBF3D605 for ; Sun, 30 Aug 2009 11:47:06 -0400 (EDT) Original-Received: from unquote (unknown [83.37.98.58]) (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 1DC3B3D604 for ; Sun, 30 Aug 2009 11:47:03 -0400 (EDT) In-Reply-To: (Andy Wingo's message of "Sat, 29 Aug 2009 13:38:13 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 5E9AF1D2-957C-11DE-A5DF-8B19076EA04E-02397024!a-pb-sasl-sd.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:9212 Archived-At: Hey folks, I'd like to outline something of a plan. The general outline is first to simplify dispatch, then to pull it into the VM. Ideally I would like to have only three kinds of procedures: VM procedures, subrs, and applicable structs. It might not be possible to simplify all of these, but we can try. We need to pay special attention to avoiding unnecessary C API incompatibilities, but hopefully we have sufficient room for refactoring. On Sat 29 Aug 2009 13:38, Andy Wingo writes: > scm_tc7_program VM procedures > - native support Yep. > scm_tcs_closures Interpreted procedures I am hoping to devise a way never to see these in the VM, on the eval-cleanup branch. > scm_tc7_subr_2o SCM (*) () -- 0 arguments. > scm_tc7_subr_1 SCM (*) (SCM) -- 1 argument. > scm_tc7_subr_1o SCM (*) (SCM) -- 1 optional argument. > scm_tc7_subr_2o SCM (*) (SCM, SCM) -- 2 required args. > scm_tc7_subr_2o SCM (*) (SCM, SCM) -- 2 optional args. > scm_tc7_subr_3 SCM (*) (SCM, SCM, SCM) -- 3 required args. > scm_tc7_lsubr SCM (*) (SCM) -- list subrs > scm_tc7_lsubr_2 SCM (*) (SCM, SCM, SCM) I would like to make these all be gsubrs. There are very few places where these constants actually exist in code "out there" -- normally the way to do this is to use scm_c_define_gsubr, and it does the right thing. I'll probably do a: #define scm_tc7_subr_2o \ scm_tc7_subr_2o_NO_LONGER_EXISTS_USE_scm_c_define_gsubr or something like that. > scm_tc7_dsubr double (*) (double) -- double subrs I'll remove these, changing their implementations to be gsubrs. This only affects $sin et al; I'll probably roll the transcendental versions into the subrs as well. > scm_tc7_cxr c[da]+r I'll change these to be subrs. > scm_tc7_asubr SCM (*) (SCM, SCM) -- "accumulating" subrs. These are interesting. We have to keep the C signature of e.g. scm_sum, otherwise many things would break. So I'd change scm_sum to be a gsubr with two optional arguments, and then on the Scheme level do something like: (define + (let (($+ +)) (lambda args (cond ((null? args) ($+)) ((null? (cdr args)) ($+ (car args))) ((null? (cddr args)) ($+ (car args) (cadr args))) (else (apply + ($+ (car args) (cadr args)) (cddr args))))))) The VM already compiles (+ a b c) to (add (add a b) c), where add is a primitive binary instruction. > scm_tc7_rpsubr SCM (*) (SCM, SCM) -- predicate subrs. Likewise, we'll have to do something like the + case. > scm_tc7_smob Applicable smobs Well... we probably have to support these also as a primitive procedure type. It could be we rework smobs in terms of structs, and if that happens, we can use applicable structs -- but barring that, this would be a fourth procedure type. > scm_tc7_gsubr Generic subrs Actually applying gsubrs can be complicated, due to optional args, rest args, and the lack of `apply' in C. I guess we should farm out application to a scm_i_gsubr_applyv trampoline that takes its args as an on-the-stack vector. > scm_tc7_pws Procedures with setters > Gets the procedure, and applies that. This needs to be inlined into > the VM to preserve tail recursion. Ideally these would be implemented as applicable structs. We'll see. > scm_tcs_struct Applicable structs Check if the struct is applicable, and if so apply its effective method. Well, that's my plan. Let me know if you have any concerns. This work is probably not for this release. Andy -- http://wingolog.org/