Re: Argh! Module system frustration.

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <address@hidden> writes:

    Marius> Excellent!  Please tell me what part I should work on.

    Marius> I was thinking about showing people how to put their new
    Marius> primitives into a module, how to make that module visible
    Marius> in guile-user, and how to evaluate code in guile-user.

    Marius> Then show some examples of how to let the user actually
    Marius> influence the behavior of the application (letting the
    Marius> user set variables, calling out the user supplied
    Marius> functions, etc.)

    Marius> Then try to point out the advantages (and disadvantages)
    Marius> of packaging an application as a library.

This all sounds great.  The structure that I have in mind for Part II
is something like this:

- Programming Overview
  - General discussion [already begun in program.texi]
- Intro to Scheme programming
  [this is the existing `Basic Ideas in Scheme' chapter]
- Guile C Programming
  - defining primitives and variables
    - interaction with modules and extensions address@hidden
  - smobs
  - awareness of memory management and GC
  - interrupts and threading models
  [plus anything else about the SCM interface that is better covered
  here than as reference-style doc in Part III]
  - internals [whatever is left over from data-rep.texi]
- Utilities
  - Snarfing
  - Docs generation
  - Debugging etc.
    - Using the debugger
    - GDB tips
    - trace
    - profiling
  - Emacs interface
- Packaging
  - as modules
  - as executable scripts
  - as extensions/libraries address@hidden
  - autoconf helper macros
  - handling versioning and deprecation

And, of course, all with lots of helpful examples everywhere.  I think
the docs that you propose writing would fit nicely at the places
marked with address@hidden

    >> - The general area of modules and variables etc. is also high
    >> on my list of doc to work on next.  (In fact I was planning to
    >> do this tonight, but now I'll wait a bit!)  This priority is
    >> motivated by the frequency of related questions on the mailing
    >> list.

    Marius> Yes.  If you can provide a framework where reference
    Marius> information needs to be filled in, that would it make easy
    Marius> for others to provide that information.

Right.  I'll try to do this.  In the particular case of modules and
variables, I think it makes best sense to move the documentation for
variables into the chapter on modules.

Regards,
        Neil