Re: Contributions to Guile

[Christopher Allan Webber]

Chad Albers writes:

> Hi Ludo,
>
> Thanks for getting back to me.  I am most interested in remedying the
> pain points that I have encountered while developing guile code.
>
> The pain points I experienced are the following:
>
> a. Simple reference guide.  The guile manual is more of a guide than a
> reference...the best way to find information is by grepping it or
> google search. I'm thinking API documentation with perhaps examples.

Funny, I find kind of the opposite... the manual is an amazing reference
guide but was difficult as a tutorial for me.  (So I've been spending
some time on a tutorial...)

> b. More robust documentation system - texinfo is not the greatest. And
> it's non-trivial to generate any documentation (including texinfo) for
> modules.

Texinfo is pretty nice to use if you're an emacs user... in fact, if
you're an emacs user, it's the best documentation reading system in the
world.  But not everyone's an emacs user.

If the html export was nicely themed, that could help a lot.  Maybe
other things could also be done, I'm not sure.  I've been having fun
with Skribilo which has info export, though it's not always very nice
looking.  I think porting the main manual would be a lot of work
though...

> c. A real packaging system...includes specification, package
> retrieval, and package hosting, package search.  Finding and including
> third-party guile code is difficult at best.

Have you looked at Guildhall?  Sadly nobody is working on it really.
This comes up a lot though...

I've been working on porting packages to Guix when I need them, but
admittedly Guix has not won enough world mindshare to be "the answer"
here.

> d. An easier build system. I see most projects using autoconf and
> make. Using build tools designed for the C language presents a higher
> barrier to those that want to contribute libraries to the guile
> community.

If it were clear *how* to use autoconf for my Guile project, or how to
get started properly, I wouldn't mind so much.  However for every Guile
project I've started I've copy-pasta'ed someone else's autotools config
files and mashed until they worked.  But I've never understood *why*
they've worked.

I'm not super excited dealing with all the m4-expanded shell, I'd still
love a Guile based autotools replacement that implements the ./configure
&& make interface still.  I'm not sure it'll happen.  Maybe someone will
pick it up?

In the meanwhile we've had some conversations about this, see David
Thompson's RFC on a Guile project generator:

  https://lists.gnu.org/archive/html/guile-user/2015-09/msg00042.html

> e. Refactors - I have a _long_ list in my head, but here's one: the
> "ice-9" namespace is cute but confusing to the beginner I once was.

Yes, I encountered frustration here too.  It's faded to the background
now, but I think ice-9 is confusing for newcomers, so is srfi-*.  As
much as I love robots, these robot names are kind of jarring.  We've
talked about some ice-9 stuff being factored into (guile foo) instead of
(ice-9 foo) but I think Mark Weaver said he'd want a lot of careful
cleanup going through that process (could be misremembering).  Some talk
of aliases for srfi modules was made as well..

> Please don't take these of criticisms of the project per se.  These
> are simply the pain points I encountered when I move from other Lisps
> (schemes and clojure) into guile. I'm inclined to take on the more
> technical/coding tasks like c, d, e.
>
> I'm not sure any of these tasks are a priority for the guile project.
> Most of the technical task match my use case - using guile as a
> full-fledged scheme interpreter rather than as an extension language.
> I'm throwing them out there to determine if any of them are priorities
> that would be welcome contributions.

I agree with most of your points, at least within some kind of scope,
clarified above!  I'd love to see movement on them.

If you really want to work on (c) and (d) there are probably two routes:
 - Implement David's RFC for a Guile project generator
 - or, keep going with Guildhall and the guild package format stuff.  We
   could then even try to build tooling in Guix to incorporate this
   stuff.

Anyway, thanks for the thoughtful comments!

 - Chris