This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



Summary:  doing this with guile will let you use all the toys that
guile has.  The syntax can be anything you like; schemey syntax will
be easier to add. 

<SNIP>

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

<snip>

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

Well, first, why would you want to use guile?  Using guile would give
you all the cool toys that guile has --- garbage collection, POSIX
utilities, complex control-flow operators, lists, associative arrays,
regular expressions, etc. 

What would be involved in using guile?  The ideal way for a new
project is to write a parser in scheme.  You could either write one
from string-manipulation primitives or the lex and yacc modules for
guile.  Or, if you've got the parser written already, you could
persuade it to emit scheme code.  This would translate your input
syntax into scheme code, transparently to the user (no parens!).
Then, anything your input syntax allows can be converted to scheme and
run.  One way to make sure that your syntax is as powerful as guile is
to allow scheme expressions verbatim, but there are many other
ways.  CTAX provides a C-like syntax for guile.  Think of it as a
compiler that produces LISP machine opcodes. 

That's the idea; what practical stuff is involved?  Well, you'd have
to link with libguile (painless), make all your C code scheme-safe
(not difficult, unless you're using the XOR-pointers hack), and get a
parser working.  Your own is probably convertible to output scheme
code.  Writing it in raw scheme is probably not fun (esp if you don't
like parens).  Using lex and yacc is a bit complicated: they haven't
been used much lately, so they're a bit rusty.  I'm working on oiling
them, but they're quite slow on my 386, so debugging them is
non-trivial.  But if you're interested, I could just pacakage them up;
they should be basically usable.  As for performance, guile will use
some memory, but be fairly fast.  lex and yacc will use more memory
and take a while to start up on my 386.  YMMV

Anyway, I recommend taking a look at guile if you're interested in
making this a powerful language; if it's just supposed to be a toy,
it's probably not worth the trouble.  But guile will let you use any
syntax you want.  

<example snipped>

Andrew
aarchiba@undergrad.math.uwaterloo.ca