Re: First look at Guile Std Library available

[Andy Wingo <wingo@pobox.com>]

Hi Richard,

Sorry I didn't respond when the thread was fresh, I was on holiday...

On Sun, 04 Jan 2004, Richard Todd wrote:

> Paul Jarc wrote:
> >As long as the code exists, I don't think there's much benefit in
> >aggregating it.  It just has to be easy for users to find.
> 
> Ok, I am definitely starting to feel like a stranger in a strange land, 
> here.

It's weird, no? I too am a newcomer to the scheme world (I'm a GNOME
hacker, really) and I'm baffled by the response. It's just so damn easy
to make a perl module, pop it up on CPAN, and have it available to
anyone with the base CPAN installation. It is one of the key factors in
perl's ascendence as a scripting language. I agree that it's desirable
for Guile, especially once you start to write apps in Guile itself. And
what a waste to write something and have it languish on a forgotten web
page.

So I share your spirit. I do have a concern about versioning, however.
Versioning the whole thing will be unwieldy as the package expands in
size. Then we have the problem of guile modules that link to C libraries
that may or may not be available, or whose available versions correspond
to only one module interface. It becomes clear that a provide/require
interface is needed as well, although it might not be implemented by
SLIB.

 [ SLIB's virtue and weakness is that it is a cathedral product. Virtue,
   because you know it's well designed and stable, but weakness because
   you or I don't feel attracted to contributing, especially
   contributing modules whose code is useful but maybe weaker than
   Jaffer's. ]

OK, punt the question about C library-backed guile modules for another
day. But for changing interfaces in scheme modules, what is needed is a
versioned `use-modules', maybe like (use-modules (math primes 1)).

Actually now that I think about it you can play nifty tricks with this.
Maybe you have a 1.2 and a 1.1 series of your primes module. So you
have

(define-module (math primes 1 1))
... code ...

(define-module (math primes 1 2))
... interface is different ...

Then you can have

(define-module (math primes 1))
;; re-export the interface of the latest version in the 1.x series
(module-use! (current-module) (resolve-interface '(math primes 1 2)))

(define-module (math primes))
;; The 1.x series is the latest one
(module-use! (current-module) (resolve-interface '(math primes 1)))

So, use (math primes) while you're developing, but then before you
release change the use-modules statement on your code to reflect the
version you are using. It's kindof like linking, I guess. Still a PITA
though.

My concern is that we don't fall in the pit of having to change module
names (think (use (gfxlib sdl1.3debian+4)) or something). Maybe my
concern is overblown, like this isn't such a big deal in interpreted
languages or something.

So thoughts about versioning in general, and this method in particular?

Regards,

wingo.


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