guile-lib things

guile-lib things

[Andy Wingo]

Hey folks,

Some thoughts about guile-lib. If you're not interested,
(++! current-message). However, if you've written something for which
you'd like wide distribution, read on to see what the atmosphere is
around guile-lib distribution.

        First things first: guile-lib needs a mailing list (perhaps 2:
        -announce and -devel), a proper web page, and some documentation
        as to _where exactly is the canonical arch archive_, and where
        the tarballs are. Input from the smart folks on guile-* is
        useful, but let's not clutter up their inboxes.

Some of this is rambling...

I've been integrating some code from other people into guile-lib. It's
tricky. The conflict is the coherence of guile-lib versus the coherence
of the upstream code itself. If the package is being currently
maintained, such as SSAX, you can't really change much, because
otherwise maintainance will be a nightmare, and the authors might call
your version heretical or something. However, you can't *not* modify at
all, because you at least have to add module headers and exports.

Furthermore, if the original author provides a module name, you might
want the name to be different, so that it fits in with guile-lib[0]. To
a lesser degree, if the name of the upstream source file sucks, you
might want to change it. Then of course it needs a copyright block, and
an arch id, then you might want to give it a proper commentary, then you
might want to give the functions docstrings[1] instead of preceding
comments, and factor out the tests into a guile-lib testsuite, and then
rename some functions...

Of course we won't rename functions that belong to a package, though. We
have to do something to ensure the integrity of guile-lib, but we can't
violate the integrity of a package. For example, there is a function in
one SXML module, SRV:send-reply. The naming is ridiculous: there is no
SRV package, and all the function does is traverse a tree, printing out
the leaves (and executing thunks). But we can't change it, because it's
in a bunch of upstream docs, and users acquainted with the package would
be a bit confused. 

Besides that, the main conflict I feel is the integrity of the package
versus having a guile-lib that is self-documenting. If comments are in a
commentary block, they are much more useful[2]. Furthermore, if they are
marked up as texinfo, they can be processed into other forms (eg html,
plain text) via the (sxml texinfo ...) modules. However, transforming
the documentation within a module's comments into this form is a lot of
tedious work that ultimately isn't maintainable.

I wanted to lay these conflicts out on the table, so that the choices we
make as distributors/packagers/coders are more coherent (that word
again!), and so that we can discuss them. Perhaps they are indicative of
the fundamental problem of guile-lib: it's centralized. Compared to
something like asdf or CPAN, we're doing too much work. But then unlike
CL or Perl, Scheme doesn't have a standard module system. Thoughts on
how to decentralize, or the merits of decentralization, are certainly
welcome.

Well, that's it for my ramble! Keep hackin, folks.

Wingo.

[0] At one point, I wanted strictly taxonomic names for the modules. I 
    was wrong: code doesn't behave taxonomically, it behaves in a 
    certain quirky way depending on who wrote it / what package it comes
    from. So while you might classify _packages_ a certain way, the 
    code often deserves to be classified under the package name itself.
    I'm thinking of (sxml htmlprag) here.

[1] guile-1.6 doesn't "notice" docstrings at all when memoizing. 1.7 
    does, but keeps them in the memoized output still -- we need to put
    them in (object-documentation foo) if docs are present, and elide 
    them from the memoized output. Thus, at present, docstrings impose
    a performance penalty. A FIXME indeed!

[2] These docs are completely generated[3]:
    http://ambient.2y.net/wingo/software/guile-lib/

[3] http://ambient.2y.net/wingo/software/guile-lib/index.scm
-- 
Andy Wingo <wingo@pobox.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Andy Wingo]

On Thu, 2004-06-24 at 19:03 +0100, Andy Wingo wrote:
> Some thoughts about guile-lib.

Yikes, it seems they do have a mailing list, and the arch archive is
documented! (I swear it wasn't, last time I looked.) Anyway, these are
the disadvantages of living in the bush.

The concerns are still valid, methinks, but let's continue the
discussion over at guile-lib-dev@gna.org.

Cheers,
-- 
Andy Wingo <wingo@pobox.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Rob Browning]

Andy Wingo <wingo@pobox.com> writes:

> [0] At one point, I wanted strictly taxonomic names for the
> modules. I was wrong: code doesn't behave taxonomically, it behaves
> in a certain quirky way depending on who wrote it / what package it
> comes from. So while you might classify _packages_ a certain way,
> the code often deserves to be classified under the package name
> itself.  I'm thinking of (sxml htmlprag) here.

Also, paraphrased from a message I sent recently:

  All of this definitely goes in the FWIW category, and also note also
  that I'm not describing a firm conviction here so much as a general
  inclination.

  That said, I tend to prefer flatter namespaces for modules when
  there's a choice.  For example, modules like (text regexp pcre), (db
  relational sql postgresql), or even (graphics opengl) seem
  unnecessary and even potentially confusing to me.

  It appears easy to get in situations where the classifications are
  multi-dimensional and the choice to put a particular module in a
  given place is just arbitrary.  For example, instead of the above,
  why not just (pcre), (opengl), and (postgresql)?  I might even
  prefer (goops) to the current (oop goops) since the oop doesn't
  really seem to add anything.

  Note that I'm not arguing for a completely flat namespace, just
  expressing a general uneasiness with the "deep generic taxonomy"
  approach I've seen in other languages.

  FWIW, and thanks.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Linas Vepstas]

On Fri, Jun 25, 2004 at 01:31:29PM -0500, Rob Browning was heard to remark:
> Andy Wingo <wingo@pobox.com> writes:
> 
> > [0] At one point, I wanted strictly taxonomic names for the
> > modules. I was wrong: code doesn't behave taxonomically, it behaves
> > in a certain quirky way depending on who wrote it / what package it
> > comes from. So while you might classify _packages_ a certain way,
> > the code often deserves to be classified under the package name
> > itself.  I'm thinking of (sxml htmlprag) here.
> 
>   That said, I tend to prefer flatter namespaces for modules when
>   there's a choice.  For example, modules like (text regexp pcre), (db
>   relational sql postgresql), or even (graphics opengl) seem
>   unnecessary and even potentially confusing to me.

Yes!  Deep taxonomies also hinder authors who are working on
new stuff, which tends to cross boundaries: if it could be easily
classified, it would be a whole lot more boring, and maybe not
worth doing ....  For example, suppose you had to classify a blog 
tool, say 5 years ago.  What category would you have put it then?  
Is slashdot a blog or a news agregator?  Who knows? 

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Andy Wingo]

Hey folks,

Ya'll have made me nearly reverse my position, FBOFW :P

On Sun, 2004-06-27 at 16:43 -0500, Linas Vepstas wrote:
> On Fri, Jun 25, 2004 at 01:31:29PM -0500, Rob Browning was heard to remark:
> > Andy Wingo <wingo@pobox.com> writes:
> > 
> > > [0] At one point, I wanted strictly taxonomic names for the
> > > modules.
> >
> >   That said, I tend to prefer flatter namespaces for modules when
> >   there's a choice.  For example, modules like (text regexp pcre), (db
> >   relational sql postgresql), or even (graphics opengl) seem
> >   unnecessary and even potentially confusing to me.
> 
> Yes!  Deep taxonomies also hinder authors who are working on
> new stuff, which tends to cross boundaries: if it could be easily
> classified, it would be a whole lot more boring, and maybe not
> worth doing ....  For example, suppose you had to classify a blog 
> tool, say 5 years ago.  What category would you have put it then?  
> Is slashdot a blog or a news agregator?  Who knows? 

This strikes me two ways:

One, that the examples you give are examples of applications, not of
library routines. Modules == library routines, syntax, hooks, etc. Most
larger applications will have modules, of course, but that's separate --
those modules would be part of the app, not part of a library.

The second way this strikes me is that many guile programmers want flat
hierarchies. Your statement has been echoed quite a bit in the past. At
the risk of resurrecting horses only to beat them yet again, I'd make
some assertions:

1) There is a place for hierarchy in modules.

I take as evidence:

(a) Packages can have pieces. In my case, I built a texinfo processing
framework. There's a parser, an html transformer, a plain-text
transformer, etc etc etc. (texinfo-parse), (texinfo-to-html), etc are
manifestly stupid names, and moreover hierarchy is encoded in their
names already.

(b) Routines might be small enough that they don't have a package
identity. Most things in ice-9 are that way. Modules in ice-9 would
benefit from some kind of classification. (Is this true?)

2) Deep taxonomic hierarchies are too rigid.

Evidence again:

(a) Hierarchy doesn't appear in python or perl modules, except in the
case that all modules are part of the same package, or extend a common
package. Same in C (flat library namespace), same in Debian (flat
package namespace). If packages are classified, it's only for
presentation and not in ways that matter.

Corollary: taxonomic hierarchies in guile-lib as it stands indicate that
it considers itself to be the package, and is thus not, in its current
form, a suitable distribution mechanism for third-party code.

(b) Classifications change.


So, if guile-lib wants to be a distribution point (through a centralized
mechanism or otherwise), it should adopt a flat module hierarchy. If, on
the other hand, it views itself as a single package, then the answer is
less clear. This case is closer to slib, whose documentation is ordered
taxonomically, but whose require namespace is flat.

I guess this really comes down to the question, "What is guile-lib?" Is
it a distribution point, or is it an slib? (Although slib suffers a
similar dilemma: a debugger, for example, surely has an identity as a
package, not just some routines.) What is the virtue of another slib?
Should guile-lib take things from slib, just because it's easier for
guile (think modules, insulation against slib changes)? If it is in fact
an slib, should it have a (lib ...) prefix, as would be suggested by the
guile-lib name? Is it just another ice-9, but perhaps one whose
development hasn't calcified?

I've been a bit schitzophrenic about the answer to that question lately.
In the end, guile-lib is what people make it, so input from all is
welcome to make it a resource of maximum utility. I'm still ruminating
my answer to that, perhaps more later in the week.

Cheers,
-- 
Andy Wingo <wingo@pobox.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Rob Browning]

Andy Wingo <wingo@pobox.com> writes:

> (a) Packages can have pieces. In my case, I built a texinfo
> processing framework. There's a parser, an html transformer, a
> plain-text transformer, etc etc etc. (texinfo-parse),
> (texinfo-to-html), etc are manifestly stupid names, and moreover
> hierarchy is encoded in their names already.

For what it's worth, one part that I snipped from my earlier message
(just to make it more concise) basically agress with you here.  Note
that I'm not arguing against having any hierarchy, I was just noting
that I'm a bit suspicious of deep/generic module taxonomies.

I think segmentation within a given coherent sub-system, say (texinfo
html) and (texinfo parse) or (gtk canvas) and (gtk text-area), is
often a fine idea.  Similarly, I have no problem with using
sub-modules for disambiguation -- i.e. perhaps (ttn graph) and (wingo
graph) rather than (ttn-graph) and (wingo-graph), or more concretely,
say (slib format), (slib uri), and (slib posix-time), if slib were
represented directly as guile modules.

The deeper generic taxonomies also make me wonder if for many
purposes, perhaps something like a keyword based search facility would
be more appropriate -- so you can support something like (find-modules
"database" 'and "relational"), (find-modules "database" 'and
"object-oriented"), or perhaps (find-modules "database" 'and
"contact").

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Andy Wingo]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Hey Rob,

On Wed, 2004-06-30 at 17:20 -0500, Rob Browning wrote:
> For what it's worth, one part that I snipped from my earlier message
> (just to make it more concise) basically agress with you here.

That's cool. It's good to see we have a consensus about something :-)

> more concretely, say (slib format), (slib uri), and (slib posix-time),
>  if slib were represented directly as guile modules.

This is interesting! I think I know how it could be done, too. Set a
custom module binder proc to (slib). Since submodules are (stupidly!)
bound to symbols within the parent module, we could catch undefined
symbols, and then require the lib. Bling. The tricky thing would be to
make sure that the interface of the modules doesn't also exhibit this
behavior.

Oh this is interesting indeed. I hacked up a prototype, and attached it.
First you have to use (slib), which sets up the lazy binder. Then when
you use (slib foo), it tries to require the foo. It's very much tied to
guile's module implementation, which is pretty evil, but it does work:

(use-modules ((slib) (slib stdio)))
(printf "%s" "Hello world!")
=| Hello world!

-- 
Andy Wingo <wingo@pobox.com>
http://ambient.2y.net/wingo/

[-- Attachment #2: Type: text/x-scheme, Size: 1290 bytes --]

(define-module (slib))

(define slib-module (current-module))

;; The issue: the binder proc can't reference any variables that aren't
;; local to this module, due to the lookup order in module_variable in
;; modules.c. So we put the binder in its own module.

(define-module (slib %binder-module)
  #:use-module (ice-9 slib))

(define (binder module sym define?)
  (pk sym)
  (and (not (eq? sym '%module-public-interface))
       (let ((new-mod (make-module 31)))
         (set-module-kind! new-mod 'directory)
         (set-module-name! new-mod `(slib ,sym))
         (beautify-user-module! new-mod)
         (module-use! new-mod (resolve-interface '(ice-9 slib)))
         (and
          (false-if-exception
           (let ((old-module #f))
             (dynamic-wind
                 (lambda () (set! old-module (set-current-module new-mod)))
                 (lambda () (require sym) #t)
                 (lambda () (set-current-module old-module)))))
          (begin
            (module-use! (module-public-interface new-mod) new-mod)
            (make-variable new-mod))))))

(define-module (slib))

(set-module-binder! slib-module
                    (module-ref (resolve-module '(slib %binder-module))
                                'binder))

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Thien-Thi Nguyen]

   From: Andy Wingo <wingo@pobox.com>
   Date: Tue, 29 Jun 2004 18:43:51 +0100

   2) Deep taxonomic hierarchies are too rigid.

any single taxonomy is too rigid.

probably if you wish to choose a single taxonomy, whether it is shallow
or deep, it will not fit w/ someone's world view somewhere.  however, if
you choose a single meta-language for describing and extending the "site
taxonomy", you have a better chance of creating something more flexible
and thus more generally useful, if the meta-language is complete.

for example, many "package systems" do not specify the contents of the
packages they provide, but instead specify a stylized interaction of the
packages w/ each other as well as w/ the package system.  a complete
system accomodates mostly-same-but-slightly-different alternatives for
both internal as well as external elements.

perhaps you (or whoever) could design guile-lib as the packaging system
for guile modules (both text and binary) and let interested programmers
do the rest.  a good exercise would be to see how to fit SLIB into such
a system, the figure of merit being the low amount of glue code and/or
manual typing required.  specify conformance but allow for indirection
as an implementation strategy instead of requiring change.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Linas Vepstas]

On Sat, Jul 03, 2004 at 06:48:29PM +0200, Thien-Thi Nguyen was heard to remark:
> perhaps you (or whoever) could design guile-lib as the packaging system
> for guile modules (both text and binary) and let interested programmers
> do the rest.  a good exercise would be to see how to fit SLIB into such
> a system, the figure of merit being the low amount of glue code and/or
> manual typing required.  

Great example.  For years, GnuCash required users (classic lusers:
non-programmers but early-linux-adopters) who were installing GnuCash
for the first time ever to type some cryptic stuff as root to complete
the install of slib.   Later this got simplified to "run gnucash
once as root" which is still pretty cryptic, as well as being a security 
exposure. 

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

ASDF for guile (Was Re: guile-lib things)

[Chris Hall]

[-- Attachment #1.1: Type: text/plain, Size: 2413 bytes --]

Andy Wingo <wingo@pobox.com> writes:

> I wanted to lay these conflicts out on the table, so that the choices we
> make as distributors/packagers/coders are more coherent (that word
> again!), and so that we can discuss them. Perhaps they are indicative of
> the fundamental problem of guile-lib: it's centralized. Compared to
> something like asdf or CPAN, we're doing too much work. But then unlike
> CL or Perl, Scheme doesn't have a standard module system. Thoughts on

Sorry - I'm a little confused by the terminology here.

By "standard module system" do you mean a standard
distribution/build/install system?  Isn't that what asdf/CPAN do?

IIUC, neither asdf nor CPAN are part of the language, or official in
anyway - they are simply "standard" by way of popularity and common
usage?

> how to decentralize, or the merits of decentralization, are certainly
> welcome.

I'd vote for de-centralized, even though each has its pluses and
minuses.  A de-centralized system would seem to provide more freedom for
the individual developers/packagers/maintainers, and would likely reduce
the time needed to get updates distributed.

This, hopefully, would allowing for faster development, feedback, etc.

On a related note:  how feasible would an 'asdf for guile' be?  Is there
a need for such a thing?

It seems to me that guile is *more* appropriate than lisp for this sort
of task, since guile is already so integrated to its host OS, and
doesn't have to worry nearly as much - if at all - about other guile
'flavors' - lisp has so many different semi-compatible 'flavors' it is a
real issue and constant topic of discussion on c.l.lisp.

I've only recently begun using guile, though I have installed several
'add-ons' already.  I have also used asdf to install lisp software, as
well as asdf's pre-cursor/inspiration 'mk-system'.  (Or was it
'defsystem'?)

Some asdf packages compile C modules they provide for FFI (foreign
function interface) purposes - this certainly seems similar to guile's
capability as an extension language.

It does seem that the amazing 'make' facility in use by so many free (as
in speech) packages is overkill for a lot of purposes, never mind the
challenges of doing a good make procedure.  For guile-only (no C)
packages especially a version of asdf for guile would seem golden.

Hmmm.

+Chris

-- 
Everywhere is walking distance if you have the time.
-- Steven Wright (1955 - )

[-- Attachment #1.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: ASDF for guile (Was Re: guile-lib things)

[Matthew Trout]

On Sat, Jun 26, 2004 at 03:22:30PM -1000, Chris Hall wrote:
> IIUC, neither asdf nor CPAN are part of the language, or official in
> anyway - they are simply "standard" by way of popularity and common
> usage?

CPAN.pm has shipped as part of core perl since time immemorial - so it's
certainly officially recommended.

> It does seem that the amazing 'make' facility in use by so many free (as
> in speech) packages is overkill for a lot of purposes, never mind the
> challenges of doing a good make procedure.  For guile-only (no C)
> packages especially a version of asdf for guile would seem golden.

Perl is going this path - the new Module::Build system which is steadily
gaining popularity for new modules (mine included) is Makefile-free, as opposed
to the older 'perl Makefile.PL; make; make test; make install' installation
style. CPAN.pm currently handles both, and I think it might be nice if we had
a single tool to install both guile-only and guile-plus-C modules as well.

-- 
Bring me my etherkiller; Oh clouds unfold! / Bring me the magic smoke of desire
I shall not cease from mental fight / Nor shall my LART rest in my hand
Till we have buried the bodies / Of all the lusers in all this land
  -- rpg, ASR                        [ My homepage is http://www.trout.me.uk/ ]


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: ASDF for guile (Was Re: guile-lib things)

[Andy Wingo]

Yo,

Just a quick reply, some more will have to come tomorrow...

On Sat, 26 Jun 2004, Chris Hall wrote:

> Andy Wingo <wingo@pobox.com> writes:
> 
> > I wanted to lay these conflicts out on the table, so that the choices we
> > make as distributors/packagers/coders are more coherent (that word
> > again!), and so that we can discuss them. Perhaps they are indicative of
> > the fundamental problem of guile-lib: it's centralized. Compared to
> > something like asdf or CPAN, we're doing too much work. But then unlike
> > CL or Perl, Scheme doesn't have a standard module system. Thoughts on
> 
> Sorry - I'm a little confused by the terminology here.
> 
> By "standard module system" do you mean a standard
> distribution/build/install system?  Isn't that what asdf/CPAN do?

No, I mean what guile calls modules, what C calls libraries, what CL
calls packages, etc. If that were standardized across all of Scheme, I
think we would see a CPAN for scheme. However, in the present situation,
any prospective author of a CPAN/asdf/... doesn't have much to work on.

If we consider guile to be the target _language_, that's a different
situation.

> > how to decentralize, or the merits of decentralization, are certainly
> > welcome.
> 
> I'd vote for de-centralized, even though each has its pluses and
> minuses.

Yeah, I'm definitely for decentralized, too. I want it to be easy to
code in guile, and a viable source of third-party code is one key
factor. So, guile-lib. But they way it is now isn't a model for _the
source_ of third party code.

A decentralized guile-lib would be more work, of course. (That's why
it's centralized now.) If there's enough interest, we could work on
specifying and implementing a decentralized system. But I won't
implement one on my own without a reasonable idea that other people
would be also walking down that same path ;)

> On a related note:  how feasible would an 'asdf for guile' be?  Is there
> a need for such a thing?

Want to design one? :-)

> It seems to me that guile is *more* appropriate than lisp for this sort
> of task, since guile is already so integrated to its host OS,

Maybe... But in the ideal world, POSIX is just another module.

> It does seem that the amazing 'make' facility in use by so many free (as
> in speech) packages is overkill for a lot of purposes, never mind the
> challenges of doing a good make procedure.  For guile-only (no C)
> packages especially a version of asdf for guile would seem golden.

I would be hesitant to abandon make, personally. (Consider, how could
g-wrap or guile-gnome be installed by such a system?) But whatever,
that's a detail.

> Hmmm.

Hmm indeed.

Regards,

Wingo.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Neil Jerram]

Hi Andy,

FWIW, I agree with the apparent consensus on all the points that have 
been made following your email, i.e.:

- avoid hierarchy for package names

- but hierarchy within a package can be useful

- consider standardizing a method for declaring keywords, then a search 
on those would provide the benefits of a hierarchical package namespace, 
but without the problems.

One other thought that I don't believe has been covered...

Andy Wingo wrote:

> Hey folks,
> 
> I've been integrating some code from other people into guile-lib. It's
> tricky. The conflict is the coherence of guile-lib versus the coherence
> of the upstream code itself. If the package is being currently
> maintained, such as SSAX, you can't really change much, because
> otherwise maintainance will be a nightmare, and the authors might call
> your version heretical or something. However, you can't *not* modify at
> all, because you at least have to add module headers and exports.

What is wrong with just this?

;;; GUILE-LIB copyright block

(define-module (ssax)
  #:export (...))

(load "upstream/ssax.scm")

(I daresay there is some problem with this, but I suspect we need to get 
into details to pin it down and find a solution.)

Regards,
    Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-lib things

[Andy Wingo]

Hi Neil,

On Thu, 2004-07-01 at 22:42 +0100, Neil Jerram wrote:
> One other thought that I don't believe has been covered...
> 
> What is wrong with just this?
> 
> ;;; GUILE-LIB copyright block
> 
> (define-module (ssax)
>   #:export (...))
> 
> (load "upstream/ssax.scm")

I like it. I don't know why this didn't occur to me.

This also allows documentation, in the form of commentaries, and as the
'documentation object property. A support macro would be nice, something
like (define-docs var docs) or so.

The only problem I see with this is if there are guile-specific
optimizations relevant to a package. Then you have to maintain a set of
private diffs. But that's not so much maintainance.

(BTW, I think ssax is part of a family of sxml processing tools produced
by oleg&co, so I call it (sxml ssax). Seems reasonable. But no
non-ssax.sf.net projects should go there.)

Thanks for the input, yo.
-- 
Andy Wingo <wingo@pobox.com>
http://ambient.2y.net/wingo/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user