unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@gnuvola.org>
To: psmith@gnu.org
Cc: guile-user@gnu.org
Subject: Re: Using guile as an extension language for GNU  make
Date: Tue, 20 Sep 2011 18:17:37 +0200	[thread overview]
Message-ID: <87iponjihq.fsf@ambire.localdomain> (raw)
In-Reply-To: <1316445274.28907.174.camel@homebase> (Paul Smith's message of "Mon, 19 Sep 2011 11:14:34 -0400")

() Paul Smith <psmith@gnu.org>
() Mon, 19 Sep 2011 11:14:34 -0400

   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...))

Even before thinking about the return value (which, scanning ahead,
you seem to have hit upon a workable plan), i have some questions
about the "some Guile program":

- Is that just a procedure call or can it be definition(s) + expression(s)?
  e.g., single proc call:
    $(guile (compute-complex-prerequisites "$@"))
  e.g., complex:
    $(guile (use-modules (srfi srfi-13))
            (define (ext filename)
              (string-append filename ".ext"))
            (define (ext-all ls)
              (map ext ls))
            (define normalize  ;;; nb: alias
              string-tokenize)
            (define (compute-complex-prerequisites s)
              (ext-all (normalize s)))
            ;; comment: do it!
            (trace 'compute-complex-prerequisites "$@")
            (compute-complex-prerequisites "$@"))

- (if the former) How would ‘compute-complex-prerequisites’ be defined?

- Would stuff like ‘normalize’ and ‘trace’ be provided (builtin)?

- What happens if the stuff inside the double quotes includes
  $(call...) or $(eval...)?  What about those constructs elsewhere?

   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.

In Scheme, w/ SRFI 13, you could express this as:

(define (as-string x)
  (cond ((not x) "")
        ((unspecified? x) "")
        ((eq? #t x) "t")
        ((string? x) x)
        ((null? x) "")
        (else (object->string x))))
        
(define (space-sep x)
  (let ((acc '()))
    (define (walk x)
      (cond ((pair? x)
             (walk (car x))
             (walk (cdr x)))
            ((null? x))
            (else
             (set! acc (cons x acc)))))
    (walk x)
    (string-join (map as-string (reverse! acc)))))
 
This is not so tricky, i think.

   Yes but implementing it in C, with the memory management etc., would be
   a lot of (not fun/interesting) work.

   Hm.  I guess I could write a little Guile program to do it for me :-).

Yes, that's the idea!

   Well, since Guile is not required and I want GNU make to continue to
   work as-is on systems where Guile is not available, I won't be rewriting
   core features in Guile.   Yet?!?!  :-).

IMHO ‘patsubst’ is not a core feature (sez the spewful ignoramus).  Rather,
i think rewriting ‘patsubst’ would be a good exercise to help you formulate
and answer questions about small technical details that will eventually serve
as a foundation for rewriting core features.  Why not give it a try?



  parent reply	other threads:[~2011-09-20 16:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-18  0:10 Using guile as an extension language for GNU make Paul Smith
2011-09-18 12:10 ` Ludovic Courtès
2011-09-18 17:21   ` Embedding vs. Extending (was: Re: Using guile as an extension language for GNU make) Paul Smith
2011-09-18 21:48     ` Embedding vs. Extending Ludovic Courtès
2011-09-18 17:42   ` Using guile as an extension language for GNU make Paul Smith
2011-09-18 21:28     ` Ludovic Courtès
2011-09-18 15:30 ` Thien-Thi Nguyen
2011-09-18 19:28   ` Paul Smith
2011-09-19  0:28     ` Thien-Thi Nguyen
2011-09-19 15:14       ` Paul Smith
2011-09-19 19:41         ` Hans Aberg
2011-09-19 21:56           ` Paul Smith
2011-09-19 22:35             ` Hans Aberg
2011-09-19 23:00             ` Hans Aberg
2011-09-21  2:42             ` Mark H Weaver
2011-09-21  8:24               ` Hans Aberg
2011-09-20 16:17         ` Thien-Thi Nguyen [this message]
2011-09-20 17:31           ` Paul Smith
2011-09-20 19:02             ` Paul Smith
2011-09-21  0:48               ` Thien-Thi Nguyen
2011-09-20 20:39             ` Thien-Thi Nguyen

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=87iponjihq.fsf@ambire.localdomain \
    --to=ttn@gnuvola.org \
    --cc=guile-user@gnu.org \
    --cc=psmith@gnu.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).