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

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

[rixed]

Hi list !

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 ?


And thanx for all the hacks !

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

[Linas Vepstas]

On 3 July 2010 00:36,  <rixed@happyleptic.org> wrote:
> Hi list !
>
> 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.
[...]
> 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 ?

I dunno quite what he meant, except perhaps to notice that there are now
a (large?) variety of open-source packages that support configuration.
So, for example, there's gnome's gconf, which has many advanced features,
e.g. allows you to define a system-wide default config, which individual users
can over-ride; you can define allowed config paramters (i.e. specify allowed
ranges, values, etc), there are some generic graphical tools for exploring/
editing these, and the C api is nearly trivial to use. etc.  Its hard to compete
with that.  I don't recall if gconf is GPL or LGPL.   gconf is C, but I presume
that KDE has some C++ variant; and there are probably others.

Personally, I have found guile best-suited for "rapid proto-typing" i.e. coding
up funky algos to drive various components in certain ways. Although
"proto-typing" is a misnomer; I have no intent of ever re-writing the good
algos in C. If anything,  the opposite is true: I'm very very slowly converting
large, bulky, clunky C code into small and fast guile code.

--linas

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

[Ludovic Courtès]

Hi,

rixed@happyleptic.org writes:

> What does he mean by that ? Are there any contraindication against using
> guile as an extention language for configuration ?

I think Guile would be best used as a configuration aid à la Emacs,
where configuration is achieved by actually “programming” the system,
sometimes without noticing, not à la fvwmrc (or any other similarly
restricted descriptive configuration file.)

Thanks,
Ludo’.

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

[Thien-Thi Nguyen]

() rixed@happyleptic.org
() Sat, 3 Jul 2010 07:36:51 +0200

   Are there any contraindication against using
   guile as an extention language for configuration ?

I don't think so.

Configuration is specialization, moved early.
Guile can handle that, as long as early is not too early.

thi

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

[Andy Wingo]

Hi!

On Sat 03 Jul 2010 06:36, rixed@happyleptic.org 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/