[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] too many core modules?
From: |
John Cowan |
Subject: |
Re: [Chicken-hackers] too many core modules? |
Date: |
Wed, 2 Sep 2009 10:41:41 -0400 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
felix winkelmann scripsit:
> > I agree, which is why I support the idea of a compound unit. Convenience
> > isn't always the predominant concern, though, especially when it comes
> > to deployment, particularly deployment as C source (regrettable though
> > that is).
>
> Reducing the number of core libraries will make deployment actually
> easier. Can you be more specific?
I recognize the validity of ease-of-use concerns; I simply ask you to
recognize that there are other concerns. Some years back, I wrote a Joy
implementation that was meant to be delivered to users in C form as a
few C files, including extras.c. I complained about the size of these,
and you very nicely pulled the relevant routines out of extras.scm for
me and put them into joy.scm.
*That's* the concern I wish to have addressed. A statically linked
executable ought not to contain dead code; dead code is untested code
and unsecured code. I realize that this goal is not fully achievable,
but I think it's worth attempting, *particularly* if a simple mechanism is
also available for those who care about ease of use more (which certainly
includes me, in some roles and moods).
--
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"
John Cowan <address@hidden>
- Re: [Chicken-hackers] too many core modules?, (continued)
Re: [Chicken-hackers] too many core modules?, Kon Lovett, 2009/09/01