[Top][All Lists]

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

Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and ev

From: Evan Hanson
Subject: Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm
Date: Sun, 4 Jun 2017 23:20:06 +1200

Hi Peter,

Sorry for the delay, I should have responded earlier.

On 2017-06-03 15:07, Peter Bex wrote:
> On Wed, May 03, 2017 at 08:29:12AM +0200, Peter Bex wrote:
> > On Mon, May 01, 2017 at 06:02:51PM +1200, Evan Hanson wrote:
> > > Hi folks,
> > > 
> > > Just wanted to mention that I've already applied the first of these
> > > patches; that one is clearly a nice change and definitely where those
> > > procedures belong, good call.
> > 
> > Is there a problem with the other ones, or have you just not had time
> > to properly review them?
> Anyone have some time to look at the remaining two patches of this
> post?  It's been sitting here without comments for a month.

I'm concerned about the way these introduce an implicit dependency from
the library unit to the internal unit.

I think we should strive to make library the first, and potentially the
only, unit that the user needs to care about when distributing compiled
C or compiling programs with "-explicit-use". These changes move things
further away from that ideal by making programs that use the `time`
macro (and probably `syntax-rules`, though I haven't looked at that
quite as closely) depend not just on library but also on internal, and
without adding anything to make sure the internal unit will actually be
loaded as necessary. An example program that will no longer work is the

    ;; compile with `csc -x example.scm`
    (import chicken)
    (time (print 1))

Even without the "-x", it's only due to the fact that the eval unit is
loaded by default that this program runs at all, since that unit depends
on internal.

So, what is the intended purpose of these changes? If it's to shrink
library.scm, I think there are probably other things in that file that
could moved more easily and that wouldn't have this problem, but if it's
just nicer organisation of CHICKEN's source code for our own sake then
I'd rather not make these particular changes.

All that said, I'm definitely in favour of dropping the optional
arguments in mini-srfi-1.scm and using that file's procedures in
csi.scm, and I'd be happy to apply those bits on their own right away.



Attachment: signature.asc
Description: PGP signature

reply via email to

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