From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Toby Cubitt Newsgroups: gmane.emacs.help Subject: Re: Writing a function/macro in Elisp that generates a function at runtime Date: Tue, 28 Oct 2008 13:42:57 +0100 Message-ID: <490708D1.4070906@dr-qubit.org> References: <4906EB9C.10501@dr-qubit.org> Reply-To: Toby Cubitt NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1225201475 5143 80.91.229.12 (28 Oct 2008 13:44:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2008 13:44:35 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Oct 28 14:45:36 2008 connect(): Connection refused Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kuosy-0006pQ-3P for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Oct 2008 14:45:28 +0100 Original-Received: from localhost ([127.0.0.1]:37198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kuorr-0005o6-Ue for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Oct 2008 09:44:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KuorQ-0005k1-Nk for help-gnu-emacs@gnu.org; Tue, 28 Oct 2008 09:43:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KuorP-0005jE-Tz for help-gnu-emacs@gnu.org; Tue, 28 Oct 2008 09:43:52 -0400 Original-Received: from [199.232.76.173] (port=54701 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KuorP-0005iy-IV for help-gnu-emacs@gnu.org; Tue, 28 Oct 2008 09:43:51 -0400 Original-Received: from mail.geekisp.com ([216.168.135.169]:6214 helo=starfish.geekisp.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KuorP-0000mN-9i for help-gnu-emacs@gnu.org; Tue, 28 Oct 2008 09:43:51 -0400 Original-Received: (qmail 23298 invoked by uid 1003); 28 Oct 2008 13:43:01 -0000 Original-Received: from [192.168.2.9] (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Tue, 28 Oct 2008 09:42:59 -0400 User-Agent: Thunderbird 2.0.0.17 (X11/20080929) In-Reply-To: <4906EB9C.10501@dr-qubit.org> X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) X-Primary-Address: toby@dr-qubit.org X-detected-operating-system: by monty-python.gnu.org: OpenBSD 3.0-3.9 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:59205 Archived-At: Toby Cubitt wrote: > Barry Margolin wrote: >> You don't need to generate a function on the fly for this. Do something >> like this: >> >> (defun insert-with-function (insfun new-data old-cell) >> (setf (cell-data old-cell) >> (funcall insfun new-data (cell-data old-cell))) >> old-cell) > > Hmmmm...the simplest ideas are always best. This does sound like a > better approach. Thanks! I've now remembered why this won't work, at least not straightforwardly. I have a higher-level data structure built on top of a lower-level one. Internally, the higher-level structure stores data "cells" in the lower-level structure. The lower-level structure of course knows nothing about this. It just stores any kind of data, without knowing anything about its structure. And users of the higher-level structure also know nothing about the data cells, which are part of the internal implementation. As far as users are concerned, they can just store data of whatever kind they like in the higher-level structure. For the lower-level structure, I have defined exactly this kind of insert-with-function, called say `low-level-insert-with-function'. What I'm trying to do is to define a `high-level-insert-with-function' for the higher-level data structure. Clearly, it has to call `low-level-insert-with-function' to insert the data into the lower-level structure on which it is build, something like: (defun high-level-insert-with-function (higher-structure data insfun) (low-level-insert-with-function (higher-structure--get-lower-structure higher-structure) data ??insfun??)) Now insfun knows nothing about the data cells, since it was passed in by the user. And `low-level-insert-with-function' knows nothing about data cells, since it acts on the lower-level data structure. So it would seem I need to wrap insfun on the fly in the above function, to make it aware that the data is actually stored within "cells". And we're back to the problem from my previous mail: how to generate a wrapped insfun on the fly, in such a way that the setf macro required to enter data into a "cell" is expanded into the cell-data accessor function at compile-time. I still don't see why this should be fundamentally impossible. The function can easily be generated on the fly by a backquote construct (as in my first attempt), and all the necessary information for macro-expanding setf is there at compile-time. It's 'just' a question of getting macro-expansion to be carried out within the backquote construct (which is what I was trying in my second attempt). Probably there's a different way of approaching the problem that I'm not seeing. Thanks for your help (and sorry for the lengthy explanation), Toby