Re: [bug-gettext] Libgettextpo wrapper for Guile

[Miguel]

(Links at the end for readability.)

Bruno Haible <address@hidden>:
> Hi Miguel,
 
Hi Bruno,

After some suggestions made by private email and being suggested in
the savannah admission process to integrate it in gettext[1], I gave a
second look into the topic, and check the pros and cons more
thoroughly.

> > an external project would be useful anyway as
> > does not require a version update of neither Gettext nor Guile to
> > start using it  
> 
> A separate project also means an independent release cycle.

This can be a problem until the library reaches an stable status, as
GNU gettext is a mature project and the library may need better advice
in some areas.  Nonetheless, the pace of evolution will be reduced
very much when some design issues are clarified[2] and a set of clear
Scheme idioms is found[3], and it will follow surely libgettextpo
evolution and not Guile.  I've tested it with Guile 2.0.14, Guile 2.2.4
and Guile 2.9.1, with all tests are working as expected.  It does not
work with Guile 1.8, as the ffi module at least was added with 2.0
release (scm_to_pointer, scm_t_pointer_finalizer, etc.) and I don't
know if it worths the effort porting it over that version, but it
could be a secondary effect of some changes in the implementation[4].

> How are other Guile bindings organized?
> - guile-cairo         separate project[5]

It seems that all language bindings are separate projects[6].

> - guile-gnome         separate project[7]

Gtk+ bindings are separate projects too, even though guile-gnome needs
some updates as it was Gtk+2 last time I played with it.

> - guile-git           separate project[8]

Git seems to have all its bindings as separate projects too.

> - libgccjit           separate project[9]

This one is quite new and I didn't know about it.  GNU Lightning is
there too and it is used for the JIT implementation in the future Guile
3.0[10].

> - zeromq              at zeromq[11]

This actually is a separate project if you look into the page.

> - guile-gnutls        at gnutls[12]
> - gmp                 part of guile[13]

AFAIK guile does not export bindings from any GMP library, but it uses
GMP internally to implement the number tower required by Scheme. 

I would like to add these examples too:

- gettext               part of guile[14]
- texinfo manipulation  part of guile[15]
- gdb                   part of gdb[16]
- mailutils             part of mailutils[17]
- make                  part of make[18]
- guile-opengl          separate project[19]
- guile-parted          separate-project[20]
- guile-gcrypt          separate project[21]

> The majority seems to have chosen to be available as separate project.

Most of them are available as separate projects, I agree.  Although I
think the integration in any of them (Guile or Gettext) benefits the
GNU Project itself[22].

> > 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  
> 
> There are no plans to use a different implementation language for
> PO file manipulations. With the existing code base as a start, it
> is not much harder to code new functionality in C than it would be
> to code it in Python, guile, Java, or other languages.
>
> Gettext needs a different implementation language in other areas -
> such as extracting relevant information from HTML pages - and is
> using POSIX sh for this purpose. It's a balance between language
> features, portability, and ease of installation / minimization of
> dependencies.

My ideas were not clear at that point, so I must retract of what I
said; your point is more than valid.

In this case I could think the extension as a user of gettext's tools,
not only as the main code of the project.  I'm probably the only
user of the library at this moment, but I'm using it for translation
tasks such as translating the same fragment of text again and again.
There is a similar library for Python[23], and gettext already has the
code to do the same task.

What do you think?

Best regards,
Miguel

[1] https://savannah.nongnu.org/task/index.php?15273
[2] The main issue in my TODO list is clarifying the non-local exits.
I'm currently checking the code, after I have enough information I'll
open a separate thread probably about this.
[3] I'm not completely confortable with the /with-po-files/ approach,
but I think it is a good idea to perform file management through
declaration than imperatively, and I'd like to evolve a bit at least
this interface, as most of the functions are mostly calls to the C
library.
[4] The (gettext po internal-api) module could be removed and the C
source could export all the needed functions instead of relying on
(system ffi).  Would this be enough?  I thought about that regarding
speed/efficiency, but that can be another reason.
[5] https://www.nongnu.org/guile-cairo/
[6] https://cairographics.org/bindings/
[7] https://www.gnu.org/software/guile-gnome/
[8] https://gitlab.com/guile-git/guile-git
[9] https://savannah.nongnu.org/projects/gccjit-guile/
[10] http://git.savannah.gnu.org/cgit/guile.git/tree/NEWS
[11] http://zeromq.org/bindings:guile-binding
[12] https://www.gnutls.org/manual/gnutls-guile.html
[13] https://gmplib.org/manual/Language-Bindings.html
[14] https://www.gnu.org/software/guile/manual/html_node/Gettext-Support.html
[15] https://www.gnu.org/software/guile/manual/html_node/texinfo.html
[16] https://sourceware.org/gdb/current/onlinedocs/gdb/Guile.html
[17] https://mailutils.org/manual/html_node/guimb.html
[18] https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html
[19] https://www.gnu.org/software/guile-opengl/
[20] https://gitlab.com/mothacehe/guile-parted
[21] https://notabug.org/cwebber/guile-gcrypt
[22] https://www.gnu.org/prep/standards/html_node/Source-Language.html
[23] https://pypi.org/project/polib/