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: Guile support in GNU make Date: Sun, 15 Jan 2012 11:12:29 -0500 Organization: GNU's Not Unix! Message-ID: <1326643949.3482.241.camel@homebase> References: <1326570905.3482.136.camel@homebase> <87boq5jqmc.fsf@gnuvola.org> Reply-To: psmith@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1326643963 684 80.91.229.12 (15 Jan 2012 16:12:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 Jan 2012 16:12:43 +0000 (UTC) Cc: guile-user@gnu.org To: Thien-Thi Nguyen Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jan 15 17:12:39 2012 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 1RmShD-0007Sj-97 for guile-user@m.gmane.org; Sun, 15 Jan 2012 17:12:39 +0100 Original-Received: from localhost ([::1]:33042 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmShC-00006G-Om for guile-user@m.gmane.org; Sun, 15 Jan 2012 11:12:38 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmSh8-000060-8Q for guile-user@gnu.org; Sun, 15 Jan 2012 11:12:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmSh6-0003HV-TL for guile-user@gnu.org; Sun, 15 Jan 2012 11:12:34 -0500 Original-Received: from oproxy8-pub.bluehost.com ([69.89.22.20]:58915) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RmSh6-0003HK-Jy for guile-user@gnu.org; Sun, 15 Jan 2012 11:12:32 -0500 Original-Received: (qmail 11221 invoked by uid 0); 15 Jan 2012 16:12:31 -0000 Original-Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy8.bluehost.com with SMTP; 15 Jan 2012 16:12:31 -0000 Original-Received: from 146-115-71-23.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.71.23] helo=[172.31.1.105]) by box531.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RmSh5-00058C-Dp; Sun, 15 Jan 2012 09:12:31 -0700 In-Reply-To: <87boq5jqmc.fsf@gnuvola.org> X-Mailer: Evolution 2.32.2 X-Identified-User: {678:box531.bluehost.com:madscie1:mad-scientist.us} {sentby:smtp auth 146.115.71.23 authed with paul+mad-scientist.us} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 69.89.22.20 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:9141 Archived-At: On Sun, 2012-01-15 at 09:51 +0100, Thien-Thi Nguyen wrote: > - In Scheme, it is customary to say "procedure" instead of "function". > I suggest 8.13.2 Interfaces from Guile to `make' explicitly state that > (for those unfamiliar w/ Scheme), and then liberally specify "function" > for Make functions and "procedure" for Scheme procedures. Excellent, thank you. That will definitely make things more clear. > - The =A1#t =3D> t=A2 distinguishes the symbol t from others, which feels= wrong. > I suggest #t =3D> ""; #f =3D> error. Hm. The problem with this is that we can't easily use Guile booleans in GNU make. For example, the syntax for make's $(if ...) function is: $(if ,[,]) The is expanded as a makefile expression and if it's empty it's considered false. If it's non-empty it's considered true. Suppose we wanted to write a Guile condition here, something like: $(guile (access? "foo" R_OK)) Under the current behavior that can be used directly: $(if $(guile (access? "foo" R_OK)),...) If we change things as you suggest we must be sure that we NEVER provide a result of #f to any procedure that is called by make's guile function otherwise make will fail. In other words we'd have to do something like this instead: $(if $(guile (if (access? "foo" R_OK) true #t)),...) Or maybe more understandable: $(if $(guile (if (access? "foo" R_OK) true "")),...) Of course we could write a procedure to do this conversion for us, but isn't that just making extra work to do what we could define the conversion to do natively? I understand the conversion of #t =3D> "t" and #f =3D> "" is strange to think about, but I'm not sure the alternatives are better. > - Give more details for =A1other =3D> error=A2. Since this feature is ne= w, > there will be many debugging opportunities :-D, so the better you > define this condition, the easier it will be for users to use, and > for you to get feedback for further iteration. I agree with this 100%... unfortunately I really have no idea what happens here or what facilities are available/appropriate for handling errors or debugging Guile programs. I will need to investigate. > Oh yeah, i forgot: I think Make vars should not be accessed by a > Scheme string, but rather a symbol Well, my concern about this is that in GNU make, anyway, we very often use constructed variable names. I would assume that the same would be true in Guile procedures, which means it will more be convenient to store variable names in strings in Guile (it seems to me) so they can be more easily manipulated. Of course you can always use symbol->string etc. But is this worth it, to require the Guile user to always perform this operation when we could do it automatically? --=20 ---------------------------------------------------------------------------= ---- Paul D. Smith Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scient= ist