Re: Trying guile as an extention language for a 'real world' product

[Andy Wingo]

Hi!

On Sat 03 Jul 2010 06:36, address@hidden writes:

> At work, I recently pushed the idea to use an extention language for our
> main product, which is a middle sized program written in C with many
> threads, that must run quickly without without interruption 24/7, and
> that have little memory nor CPU to spare.
>
> As nobody comes with a better idea, and as I'm secretly in love with
> scheme and aligned to the GNU world domination plans, this extention
> language is going to be guile.
>
> The first usage for this extention language would be to replace the
> various configuration system with a simpler and more powerfull interface
> from scheme to C configuration datas. But I just came across Andy's
> slides for ghm 2009, where he says that guile is "not so much for config
> files (days of fvwmrc long gone)".
>
> What does he mean by that ? Are there any contraindication against using
> guile as an extention language for configuration ?

Cool!

It's fine to use Guile to handle configuration. I guess what I meant
though is that it almost seems a waste to make applications like that:
Guile is so much more pleasant to hack in, it expands to fill the
tolerance for Scheme in your organization :) Also, the times have
changed a bit, and it doesn't seem that apps are made like fvwm (for
example) any more (complicated conf language).

It is a political act to use Guile as an extension language. It says
that you would like for more of your program to be hackable in
Scheme. In most organizations, it's subversive too, because you're
sneaking in technology from the Scheme underground resistance movement
:-)

A caveat, though: Guile is not the smallest Scheme. If you think that
adding 4 MB of memory use to your application would make it impossible
for you to use Scheme, then there are other, smaller ones. I hear Chibi
is good, for example. But Guile is a batteries-included Scheme with a
pleasant development environment, one that scales up to large programs,
and I at least find it to be pleasant :)

I read some of your further mails on the web but haven't downloaded them
yet, and it seems that you have a lot of state to export to your
users. I suggest making a new module and defining those variables in
that module. If you are coming from C, use scm_c_define_module, and
within the init thunk, use scm_c_define () to define all of your
variables. Evaluate your users' code within the returned module.

Happy hacking,

Andy
-- 
http://wingolog.org/