From: Paul Smith <psmith@gnu.org>
To: Thien-Thi Nguyen <ttn@gnuvola.org>
Cc: guile-user@gnu.org
Subject: Re: Guile support in GNU make
Date: Sun, 15 Jan 2012 11:12:29 -0500 [thread overview]
Message-ID: <1326643949.3482.241.camel@homebase> (raw)
In-Reply-To: <87boq5jqmc.fsf@gnuvola.org>
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 ‘#t => t’ distinguishes the symbol t from others, which feels wrong.
> I suggest #t => ""; #f => 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 <condition>,<then>[,<else>])
The <condition> 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 => "t" and
#f => "" is strange to think about, but I'm not sure the alternatives
are better.
> - Give more details for ‘other => error’. Since this feature is new,
> 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?
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@gnu.org> 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 Scientist
next prev parent reply other threads:[~2012-01-15 16:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-14 19:55 Guile support in GNU make Paul Smith
2012-01-15 8:51 ` Thien-Thi Nguyen
2012-01-15 12:33 ` Thien-Thi Nguyen
2012-01-15 16:12 ` Paul Smith [this message]
2012-01-15 20:11 ` Thien-Thi Nguyen
2012-01-15 20:49 ` Paul Smith
2012-01-15 22:02 ` Ludovic Courtès
2012-01-16 14:07 ` Paul Smith
2012-01-17 22:42 ` Ludovic Courtès
2012-01-17 23:26 ` Paul Smith
2012-01-19 20:42 ` Ludovic Courtès
2012-01-19 22:14 ` Ludovic Courtès
[not found] <1316557011.28907.237.camel@homebase>
[not found] ` <1326572016.3482.144.camel@homebase>
[not found] ` <20120122182923.GB3460@mini.zxlink>
2012-01-22 21:56 ` Paul Smith
2012-01-23 6:01 ` Thien-Thi Nguyen
2012-01-23 6:08 ` Thien-Thi Nguyen
2012-01-29 20:05 ` Paul Smith
2012-01-31 19:17 ` Kirill Smelkov
2012-01-31 21:32 ` Paul Smith
2012-01-25 23:45 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1326643949.3482.241.camel@homebase \
--to=psmith@gnu.org \
--cc=guile-user@gnu.org \
--cc=ttn@gnuvola.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).