Re: Libgettextpo wrapper for Guile

[Miguel]

Hi Bruno,

> Hi Miguel,
> 
> > I implemented a wrapper library
> > for Guile and a couple of higher level functions, tests and I'm
> > documenting everything.  
> 
> This is great. Many thanks for this contribution!!

You're welcome!  I hope it will be useful.  And it would not be
possible without your work, so actually thank you all.

> > I'd like to contribute it to GNU---a wrapper of a GNU library in the
> > official GNU extension language, I think it's sensible---, but I
> > would like to ask you where it would fit better:
> > 
> >     - In GNU gettext as part of gettext-tools?  It could cause
> >       problems in the Guile bootstrap, as several tools from
> > there are needed when NLS is enabled.  Nevertheless, it seems to be
> >       the better fit in terms of code locality and cross
> >       maintenance.  
> 
> Very good question. I think there are two aspects:
> 
>   - Development aspects. Does your guile wrapper need more know-how
>     from the guile world or from the gettext world? (*) Will it need
>     regular changes as guile evolves? Surely it will need changes
>     when gettext-po.h evolves, but gettext-po.h has been stable
>     since 2010.
>     (*) This is relevant, because when at some point in time you
>     will not want to maintain it any more, will it be more easy to
>     find a new maintainer for it among the camp of guile developers
>     or among the gettext developers?

On one hand, this Guile library is tightly coupled with libgettextpo and
its integration in the gettext world could drive some of improvements
into the C library itself, such as an extension of the iteration
interface to a bidirectional or random access one.

On the other hand, it only has one source file written in C, it is
mainly intended to the Lisp world.  Gettext's source code is mainly
written in C, with the main exception of the example code and the java
runtime.

I think the choice should have more to do with Gettext's desire as a
project to extend its code base in Guile in the future, as the Guile
library could be the foundation for new tools, or to keep C as the main
code base, a reasonable position for such a key software and its amount
of codified knowledge.

It is also coupled to Guile as it uses (system ffi), even though
that interface is quite stable too.  The other sparsely used modules
are (ice-9 format) and (ice-9 regex).  Anything else is standard Scheme
or available as an SRFI, at least that's what I've tried.

I'm sure there are plenty of people in both worlds that are able to
hack any bug in my code in an hour, and much better I'd do it.

>   - Distributions aspects. Distros will likely package it in a
>     package different from gettext and different from guile, since
>     both gettext and guile can be used without the wrapper library.
>     Right?

Yes, for sure, breaking any of them would be a huge bug. 0:-)

>     But distros are already used to create multiple binary packages
>     from a single source package.

That shouldn't be a problem, I agree.

> >     - In Guile as an ice-9 module?  As readline, it could be a
> >       GPLv3+ library, but also available from scratch.  From my
> >       point of view, it would be a great option in terms of
> >       (zero) increment of dependencies and tight integration
> > with the language.  
> 
> I don't know what an ice-9 module is.

Ice-nine is a fictional water crystal stable at room temperature from
Kurt Vonnegut's novel Cat's Cradle, that makes solid all water it comes
into contact with.  AFAIK, this reference is used in the Guile world for
the official modules that are pervasively useful, including the
bootstrapping of the language itself and libraries like readline.  I
don't remember where I've read it but I think I'm not making it up.

> I also don't know whether you can define an ice-9 module outside of
> the guile package.

You probably can, although Guile has several modules in other
namespaces too.  My wish is that it is so useful that it deserves that
name, although the module I'm using in the implementation right now is
(gettext po).  The key point for its inclusion in Guile would be its
availability right out-of-the-box, not really the name.

> >     - As an external library?  
> 
> Would you want to have a project infrastructure with mailing list,
> bug trackers, etc. for this wrapper library? I would think this is
> overkill.

I was planning to use Savannah, I've prepared the form twice but didn't
hit send yet.  It might be an overkill, that's true, but I don't want
to use other easier and faster (and with extra lack of freedom)
repository server as GH, neither keep it to myself.  Also, with a small
code base there should not be so many maintenance tasks neither, and I
think I could face that up.

Even more, it would not be available on older versions than the first
Guile release with it, so an external project would be useful anyway as
does not require a version update of neither Gettext nor Guile to start
using it, at least as some kind of "backports"---I'm not aware of any
project of this kind.

Happy hacking,
Miguel