Re: The how and why of incorportating guile into an existing project.

[Bruce Korb <korbb@datadesign.com>]

Gary V. Vaughan wrote:

> Hello.
>
> I believe you are already aware of some of this... but a brief recap:

I wrote (Wed, 02 Jul 1997 11:58:52 -0700):

> The last few days I have been futzing around with this Guile
> stuff trying to see if I can get my little autogen toy up to
> the bleeding edge in embedded language technology.  Well, I
> think I have bled to death now.  I would like to release the
> thing to the public domain, and I would like to utilize something
> to help keep the embedded language consistent with other things
> that are around.  I am soliciting *SIMPLE* suggestions before
> I cut the thing loose.
>
> Here is what the toy does:
>
> 1.  It reads in the set of values that correspond to macros
>     in one or more template files.  Generally, it specifies the tmplate.
> 2.  The template is processed, making the substitutions and
>     repetitions based on this embedded language and the
>     definitions read in. The output may be one or more files,
>     depending on the template specification and the supplied values.
>
> Below is an extraordinarily simple example of a template.
> In this example, I have defined '[=' and '=]' to start and
> end, respectively, the expansion controls and text substitutions.
>
> My questions are: How would this look in Guiled syntax?  How could it
> be kept simple?  (i.e. there will *NOT* be "Lots of Insipid Stupid
> Parentheses".  I am not parenophobic, but I also do not have an
> affinity for nested parenthetical expressions that do not add to
> clarity.  I am a clarity fanatic [this syntax not withstanding :].)
> How would I handle the guile library calls?  (I have not found
> examples that are clear to me, hence this note.)  I believe it to
> be a requirement that the embedded language markers be flexible
> from template to template.
>
>     /*
>      *  This file is [=_eval _outfile=]
>      */
>     [=_IF _SFX h = =][=
>
>     #    Remember the name of the output file so
>          the 'C' program can #include it.
>
>     =][=_SETENV HDROUT _outfile=]
>     typedef struct {
>         int    stuff;
>     } t[=type _cap=]Stuff;
>     [=_FOR foo=]
>     #define [=bar=]_STUFF [=_eval _index=][=
>     /foo "end of 'foo' loop" =]
>
>     extern t[=type _cap=]Stuff [=type _down=]Array[ [=
>          _EVAL foo _hilim 1 +=] ];
>     #define [=type _up=](n) [=type _down=]Array[ n ## _STUFF ][=
>
>
>     _ELSE "suffix is *not* 'h'"
>
>
>     =]#include "[=_eval HDROUT _env=]"
>     t[=type _cap=]Stuff [=type _down=]Array[ [=
>          _EVAL foo _hilim 1 + =] ] = {[=
>
>     _FOR foo FROM 0 BY 1 SEP ","=]
>     /* [=_eval _index #%2d _printf =] */    bar_[=bar=][=
>         _IF baz _exist=]    /* BAZ Comment: [=baz=] */[=
>         _ENDIF=][=
>     /FOO "end of _FOR loop"=] };[=
>
>     _ENDIF "header and not header"=]
>
>
> This is an example of the output of something similar, so
> you can get a fuzzy notion of how it expands.
> Note that [=_FOR foo=] expands differently than
> [=_FOR foo FROM 0 BY 1 SEP ","=].
>
>     /*
>      *  This file is TEST.h
>      */
>     typedef struct {
>         int    stuff;
>     } tSomeStuff;
>
>     #define ONE_STUFF            1
>     #define THREE_STUFF          3
>     #define FOUR_STUFF           4
>     #define NINE_STUFF           9
>     #define TWELVE_STUFF         12
>
>     extern tSomeStuff someArray[ 13 ];
>     #define SOME(n) someArray[ n ## _STUFF ]
>
>     # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
>
>     /*
>      *  This file is TEST.c
>      */
>     #include "TEST.h"
>     tSomeStuff someArray[ 13 ] = {
>     /*  0 */    bar_default   /* DEFAULTED */,
>     /*  1 */    bar_one       /* BAZ Comment: another one */,
>     /*  2 */    bar_default   /* DEFAULTED */,
>     /*  3 */    bar_three,
>     /*  4 */    bar_four,
>     /*  5 */    bar_default   /* DEFAULTED */,
>     /*  6 */    bar_default   /* DEFAULTED */,
>     /*  7 */    bar_default   /* DEFAULTED */,
>     /*  8 */    bar_default   /* DEFAULTED */,
>     /*  9 */    bar_nine,
>     /* 10 */    bar_default   /* DEFAULTED */,
>     /* 11 */    bar_default   /* DEFAULTED */,
>     /* 12 */    bar_twelve    /* BAZ Comment: baz text.
>                                * more baz text. */ };
>
> There are lots of uses for this stuff,
> even if not obvious at first glance.

Richard Stallman wrote (28 Jun 1997):

>     To represent this specification, I chose to be copy-text centric.
>     I consider this important, but first I will clarify what I mean.
>
> I understand.
>
> The decision to be copy-text centric is independent of the design of
> the programming language.  It requires using some sort of escape syntax
> to introduce programs--but once you do that, the syntax of programs
> can be anything at all.  The programming language could be designed
> for convenient programming; it need not be ad-hoc.
>
> I'd like them to be written in Scheme.

Cool.  Me, too, I think:

> Gary> Perhaps ... if you could explain how guile would be
> Gary> incorporated...
>
> He too is somewhat unclear as to how guile can fit in to autogen, and I was
> hoping you might be able to elucidate for both our benefits?