[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: First look at Guile Std Library available

From: Andy Wingo
Subject: Re: First look at Guile Std Library available
Date: Fri, 16 Jan 2004 22:17:54 +0200
User-agent: Mutt/1.5.4i

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

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'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

(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

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]