Re: Using guile as an extension language for GNU make

[Mark H Weaver]

Hi Paul,

Thanks for working on this! :)

Paul Smith <address@hidden> writes:
> So far, I have these translations (see the C code I posted earlier):
>
> t             => "t" (for make conditionals, non-empty is true)
> nil           => ""  (for make conditionals, empty is false)

Note that in modern Scheme, t and nil are just ordinary symbols, and not
booleans.  #t and #f are the boolean values, though Guile also includes
#nil in order to support other Lisps (notably Emacs Lisp).  The proper
way to test for either #nil or #f from C is to use "scm_is_false".

> "string"      => "string"
> 'symbol       => "symbol"
> 1234          => "1234"
>
> I can see that it would be nice to be able to translate:
>
> '(a b c)      => "a b c"

This all sounds great.

> But what about more complex structures like lists of lists?  What about
> simple pairs; should '(a . b) => "a b" as well?  Lists of words are just
> about all make knows about so maybe the answer is yes.

I'd recommend limiting the automatic conversion of list structure to
only proper lists of atoms, and to otherwise raise an exception.  For
unusual cases, it's easy enough to flatten the list (or even convert it
to a string) from within Scheme.

> And finally, currently I have all unknown types expanding to the empty
> string but now I'm thinking it would be better to start out more
> restrictive and throw errors.  This would ensure that people write their
> Guile scripts correctly (giving valid return values) from the start, and
> would let me, in the future, expand the supported types without breaking
> anything.

I agree wholeheartedly.  If you are too permissive, it may cause
programming errors to go unnoticed.  It's better to limit the automatic
conversions to common cases that are clearly useful.  The other cases
can be handled easily from Scheme.

As for the suggestion to look at the pretty-printing library: I don't
see why that would be useful.  The purpose of that library is primarily
to intelligently choose where to insert newlines in nested list
structure, so that lines don't grow too long for the terminal display,
and to add indentation as would be found in typical Scheme source code.
It seems to me that these functions are undesirable for this purpose.

     Best,
      Mark