chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] Eggology


From: Peter Keller
Subject: Re: [Chicken-users] Eggology
Date: Thu, 23 Aug 2007 14:13:45 -0500
User-agent: Mutt/1.4.2.1i

Hello,

On Thu, Aug 23, 2007 at 02:00:07AM +0200, felix winkelmann wrote:
> tool -> srfi-37, args-doc
> args-doc -> srfi-37, srfi-95
> srfi-95 -> array-lib
> array-lib -> srfi-42, miscmacros, misc-extn
> srfi-42 -> syntax-case
> 
> This is insane.

It might be insane, but I don't know how you are going to get around
it. What you have here is what amounts to a linking problem. Of course if
people change function signatures out from under you, things will break. :)

If you want to comprehend it, then I think a few things are needed:

1. Each egg gets a specific revision number which is sortable amongst others.
2. You could query the egg repository with these questions:
        What is the full dependancy graph from this egg on down to the leaves?
        What is the dependancy graph from this egg to all roots?
        Who is specifying hard version dependencies?
3. When you declare an egg, you give it a revision number.
4. When an egg requires other eggs, it either requires a specific
        revision, or the "latest" available revision--the default.
5. When you install an egg, you can either get the "latest" revision or
        some other revision. Since all actual codes specify what revisions they
        actually want, you only get what you need.

The only problem arises when you have two eggs wanting different revisions
of the same dependant egg. Only a clever namespace&module thingy is
going to fix that. One can look to Java for a reasonable implementation.
Sadly, though, this simply WILL happen, and sooner than one would like.

But, my real point is that you can only truly figure this stuff out if
versions and dependancies becomes a real first class object in the eggs
themselves and in the repository. Then tools can be written to just do
all of this stuff for you, much like a linker, and automatically generated
web pages could document the dependancy trees so people know what is easy
to replace, or what will be harder to replace depending upon its context.

>From my understanding, much of this stuff already exists.

-pete





reply via email to

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