() Paul Smith <psmith@gnu.org>
() Tue, 20 Sep 2011 13:31:28 -0400

   I showed the code in my original post, but the way I've implemented it
   is that the argument to the make "guile" function (that is, everything
   after the "$(guile " to the closing paren--it's handy that Guile parens
   will virtually always match, but you can use ${guile ...} instead if you
   prefer), will first be make-expanded (so all verbatim instances of "$"
   in the Guile script will need to be escaped as "$$"--it doesn't seem
   like Guile uses "$" very much so this shouldn't be too painful) and then
   the result will be passed to scm_c_eval_string().

Ah, ok.

   As far as I understand it, that means the Guile program can be as
   complex as you want.  HOWEVER, you will need to use backslashes to
   escape newlines in your example above.

Distasteful.

   You can also use make's define/endef if you want to write long Guile
   programs and avoid the need for backslashes, then you can run $(guile
   $(DEFINEDVARIABLE)).

   Then make will convert the SCM returned from scm_c_eval_string() into a
   string buffer as discussed below etc., and use that as the expansion of
   the $(guile ...) function.

OK, sounds much better.

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

   You are now running far beyond my understanding of Guile :-).  If it
   works in the environment I describe above then it will work.  If not,
   then I'll need more details.

   However I just tried your example above and I got an error "unbound
   variable: trace" so there's something missing here.  I'll have to read
   about that.

Yeah, ‘trace’ does not exist.  I think it (and other facilities) should
be defined by make, by (perhaps lazily, to avoid penalizing non-users)
loading a file, say, builtin.scm.  The minimum contents might be:

  (define-module (make-user)
    ;; builtins from C
    ;; #:use-module (make-internals)
    #:use-module (guile-user)
    #:use-module (srfi srfi-13)
    #:use-module (srfi srfi-14))
  
  (define DEBUG? (getenv "DEBUG"))
  ;; TODO: Set based on ‘-d’ exposed from C.
  
  (define (fse s . args)
    (apply simple-format (current-error-port) s args))
  
  (define (trace name . etc)
    (cond (DEBUG? (fse "hey: ~A ~S~%" name etc))))
  
  ;;; Add other convenience procs here.

Note that this doesn't export anything; the evaluation would need to
arrange to do its work with this as the "current module".  But, that's
just an idea.  You can also ‘(define-module (guile-user) ...)’ to keep
things simple initially...

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

   [standard expansion explanation]

OK, got it.

   I suppose it's possible that we could introduce a new, more advanced
   parser for the guile function that took into account quotes.  But I'm
   nervous about this: it's completely different than other expansions, and
   it might be just as annoying as doing it the other way.

I agree, that's probably to be avoided.

   > (define (as-string x) ...)
   > (define (space-sep x) ...)

   Heh, cute!  I haven't done much Lisp of any kind since I wrote a number
   of elisp packages, years ago.  I think I'll have to dust off my Scheme.

Yes, don't delay, just do it!  Playing some more, i realized the above
version 0.0 is suboptimal.  Below is version 0.1 -- perhaps it could go
into builtins.scm.

   Maybe as an exercise, but patsubst IS a core feature, in that it has
   existed forever and there are thousands of makefiles that use it...
   basically rewriting existing capabilities so they're not available if
   Guile is not present changes things from "GNU make with Guile optional"
   to "GNU make with Guile required".  I'm not ready to go there.

Right, i see the sticking point is the "re" in "rewriting".  For me, that
"re" does not imply replacement, just iteration.  My "playing at working"
MO: i skim working code and write (and integrate side-by-side-wise) a
workalike implementation based on what i think are the original's intended
design, then compare the two under load, selecting the impl to use based
on some runtime switch (typically an env var).  This leads to better
questions as understanding (and/or frustration) grows.  Even if the second
impl is inferior (ends up trashed or permanently disabled), i gain
something from the experience (although i lose time, oh well).  Anyway,
that's what i was suggesting.

I chose ‘patsubst’ because its design seems straightforward; it would be
easy to validate another impl.  No worries, i shall harp no more on this.

____________________________________________________