guile-devel
[Top][All Lists]
Advanced

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

Re: Adding stuff to the core distro (was Re: Infix syntax)


From: Lynn Winebarger
Subject: Re: Adding stuff to the core distro (was Re: Infix syntax)
Date: Fri, 18 Oct 2002 02:24:40 -0500

On Wednesday 16 October 2002 19:10, Daniel Skarda wrote:
> Lynn Winebarger <address@hidden> writes:
> > Keeping the trees separate is a proactive measure for preventing code 
> > incest.
> 
>  (I had to read this sentence few times before I fully understood it :-)

       I blame ttn for that.  I believe he's infected me with some sort of 
language
virus. ;-)   It also has the virtue of being both true and funny to say.

>  srfi-1 is very good example - it is really large module and it sometimes 
> makes
> me thinking: "I want to use only function `every' (or fold-left) - why I have 
> to
> include so BIG list library?"

    I think this misposes the question.  I should be able to have all the 
functions
in srfi-1 _presented_ in one large module, but the module system should not 
require that they are all defined in one big file, or even that I need to 
actually import
them all.  Why can't I define a bunch of little modules (possible with 
dependencies)
and then load those into srfi-1 which then exports all those names as one big 
group?
[ Or just load the subset I actually want/need ]
    Not being able to do that is a deficiency in a module system IMO.

>   What does it mean "keeping the trees separate is a proactive measure for
> preventing code incest"? If it means that every guile developer has to 
> reinvent
> the wheel again and again (because of holy grail of small set of 
> dependencies),
> than it is bad measure.

    The goal is not a small set of dependencies (per se).   It's just cleaner 
to keep
code from having more knowledge about other code than it should.  SE101.   I 
think it's a little easier to enforce this minimalism of code knowledge if you 
actually
keep code in separate directories.  If anything, I'd probably advocate 
separating
what's in the libguile directory now into smaller, mostly independent 
directories,
where a developer could be reasonably certain that to understand a piece of
code in a file they probably would only need to look at other files in that 
subdirectory,
or possibly in some header files (or possibly other subdirectories closer to 
the real
core code, i.e. eval.c).
     As I said, I think the eventual dependencies of distributions are the job 
of the
vendor, not of Guile hackers (per se).  Rob, of course, does both, but they are
separate roles and the one shouldn't unduly influence the other.  Making it
easy to reduce dependencies is probably a good idea, but because it comes from
the same basic SE101 principles I mentioned above rather than just in and
of itself.

Lynn




reply via email to

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