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

From: Rob Browning <rlb@defaultvalue.org>
Cc: Daniel Skarda <0rfelyus@ucw.cz>, guile-devel@gnu.org
Subject: Re: Adding stuff to the core distro (was Re: Infix syntax)
Date: Wed, 09 Oct 2002 15:17:38 -0500	[thread overview]
Message-ID: <87r8ezgye5.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <m33crfbhsj.fsf@laruns.ossau.uklinux.net> (Neil Jerram's message of "09 Oct 2002 19:15:08 +0100")

Neil Jerram <neil@ossau.uklinux.net> writes:

>     Rob> I not all that concerned with things that require an explicit
>     Rob> activation.  I'm more concerned with any additions to what's
>     Rob> visible in the core of guile (guile) and (guile-user) at
>     Rob> startup, and more particularly, how much happens in
>     Rob> ice-9/boot-9.scm, though to some extent that's an efficiency
>     Rob> issue as much as a semantic issue.
>
> But hang on, this is nothing to do with the size of the distro, is it?

Right.  In this case, I'm referring to the (old idea) that we might
want to clean up boot-9.scm.  I know that's not what we were
originally talking about, but I was just trying to clarify one of my
general inclinations wrt additions to guile ATM.

> So now I'm confused... should I view your comment "we'd be better off
> moving in the direction of a smaller base" as a commit-stopper or not?

Nope, not a definite commit-stopper, not unless it was a heavyweight
addition (code-wise or runtime-cost-wise) to the startup process or to
boot-9.scm.

> (Or did you mean "not in ice-9, but something like (tools infix) would
> be fine"?)

I'm OK with (ice-9 infix), though perhaps (infix-syntax) or (syntax
infix) might be better.

Also, (and more generally) I'm still not convinced that an a-priori
per-topic organization of the module space is a good idea except in
cases where it's really clear what that organization should be.  For
example, I tend to think (gtk) is at least as good as, if not better
than (graphics gtk).  However, I'd be likely to agree with
sub-sections for say (gnome print) (gnome pilot) (gnome vfs) (gnome
canvas), etc.

I also think that we shouldn't feel too much pressure to use generic
names.  In this I tend to agree with ttn's practices.  For example,
unless we were sure we'd come up with the "one true GL interface", I'd
be likely to prefer (blarg gl) or (blarg-gl) to just (gl) since we
might also have (swig-gl), (gwrap-gl), (super-smart-gl) etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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