guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile support in GNU make


From: Paul Smith
Subject: Re: Guile support in GNU make
Date: Sun, 15 Jan 2012 11:12:29 -0500

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 <address@hidden>          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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]