From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Smith Newsgroups: gmane.lisp.guile.user Subject: Re: Using guile as an extension language for GNU make Date: Mon, 19 Sep 2011 17:56:26 -0400 Organization: GNU's Not UNIX! Message-ID: <1316469386.27584.30.camel@psmith-ubeta> References: <1316304616.28907.118.camel@homebase> <87wrd5x404.fsf@ambire.localdomain> <1316374080.28907.163.camel@homebase> <87sjntwf29.fsf@ambire.localdomain> <1316445274.28907.174.camel@homebase> <6D40BC91-6E4B-4799-BE29-BD2FF6EEEB84@telia.com> Reply-To: psmith@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1316469401 32251 80.91.229.12 (19 Sep 2011 21:56:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 19 Sep 2011 21:56:41 +0000 (UTC) Cc: guile-user@gnu.org, Thien-Thi Nguyen To: Hans Aberg Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Sep 19 23:56:37 2011 Return-path: Envelope-to: guile-user@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 1R5lpM-0005BF-M3 for guile-user@m.gmane.org; Mon, 19 Sep 2011 23:56:36 +0200 Original-Received: from localhost ([::1]:59514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5lpM-0003sr-32 for guile-user@m.gmane.org; Mon, 19 Sep 2011 17:56:36 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5lpJ-0003sH-Fh for guile-user@gnu.org; Mon, 19 Sep 2011 17:56:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5lpF-0000Pn-Dz for guile-user@gnu.org; Mon, 19 Sep 2011 17:56:33 -0400 Original-Received: from mx0b-000f4101.pphosted.com ([67.231.152.146]:45203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5lpF-0000Pc-9I for guile-user@gnu.org; Mon, 19 Sep 2011 17:56:29 -0400 Original-Received: from pps.filterd (m0000687 [127.0.0.1]) by mx0b-000f4101.pphosted.com (8.14.3/8.14.3) with SMTP id p8JLuS6X002506; Mon, 19 Sep 2011 17:56:28 -0400 Original-Received: from mta1.netezza.com (mta1.netezza.com [12.148.248.132]) by mx0b-000f4101.pphosted.com with ESMTP id yx66xg8hf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Sep 2011 17:56:28 -0400 Original-Received: from [172.29.82.111] (172.29.82.111) by owa1.netezza.com (172.29.50.131) with Microsoft SMTP Server id 8.1.436.0; Mon, 19 Sep 2011 17:56:26 -0400 In-Reply-To: <6D40BC91-6E4B-4799-BE29-BD2FF6EEEB84@telia.com> X-Mailer: Evolution 2.32.2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-09-19_06:2011-09-19, 2011-09-19, 1970-01-01 signatures=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 67.231.152.146 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8810 Archived-At: On Mon, 2011-09-19 at 21:41 +0200, Hans Aberg wrote: > On 19 Sep 2011, at 17:14, Paul Smith wrote: > > > In make, everything is just words: broken up on whitespace. So for > > example, maybe someone writes a Guile function that computes a complex > > set of prerequisites for a target: > > > > target: $(guile (...some Guile program...)) > > > > The list of prerequisites is a whitespace-separated list of target > > names. If the Guile program returned a string like "dep1 dep2 dep3" > > then that would be fine with what I have. But it seems like it might be > > nice to allow the Guile script to return it as a list instead. Then I'd > > like to convert a list like '(dep1 dep2 dep3) into a string "dep1 dep2 > > dep3" (not "(dep1 dep2 dep3)" as display would do). > > > > But of course each element of the list could be something more complex, > > as well. So it gets tricky. > > How does 'make' store a list of words separated by strings internally? > If Guile converts its lists to such strings, the behavior is likely to > be fragile. It would better if 'make' converted those strings > internally to lists, and the Guile extension interaction with those > lists. Hi Hans; The first stage of make is reading in all the makefiles. As part of this, variables and functions are expanded (one line at a time) and the result is a string. The $(guile ...) make function, like all other make functions and variables, is expanded in this way, so the return value of the guile function must be converted to a string and appended to the string buffer make is constructing. Once all of the input is expanded and the expansion is added to the buffer, then make will go back and parse it (exactly how this is done is very context-dependent). The short is, I agree that Guile would not want to try to convert a list into some kind of internal make "list of words" data structure; in fact that just wouldn't work because at the time it runs there is no such thing. All we have is a buffer with whitespace-separated words. Rather, I need to define a translation from any Guile data type I want to support into a make-appropriate string (char* buffer) so it can be appended to make's read buffer, then parsed by make. For any Guile data type I can't or don't want to translate, I'll either throw a make error or else just expand to the empty string. So far, I have these translations (see the C code I posted earlier): t => "t" (for make conditionals, non-empty is true) nil => "" (for make conditionals, empty is false) "string" => "string" 'symbol => "symbol" 1234 => "1234" I can see that it would be nice to be able to translate: '(a b c) => "a b c" But what about more complex structures like lists of lists? What about simple pairs; should '(a . b) => "a b" as well? Lists of words are just about all make knows about so maybe the answer is yes. And finally, currently I have all unknown types expanding to the empty string but now I'm thinking it would be better to start out more restrictive and throw errors. This would ensure that people write their Guile scripts correctly (giving valid return values) from the start, and would let me, in the future, expand the supported types without breaking anything.