On 19 Sep 2011, at 23:56, Paul Smith wrote: > Rather, I need to define a translation from any Guile data type I want > to support into a make-appropriate string (char* buffer) so it can be > appended to make's read buffer, then parsed by make. For any Guile data > type I can't or don't want to translate, I'll either throw a make error > or else just expand to the empty string. > > 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) > "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" > > 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. > > 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.
Perhaps you should have some Guile pretty-printing object that can be manipulated from the makefile. Hans