[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: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm
Date: Sun, 4 Jun 2017 13:53:11 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Sun, Jun 04, 2017 at 11:20:06PM +1200, Evan Hanson wrote:
> 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".

I see what you mean.

> 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.

It was to shrink library.scm, but also to move an internal procedure
that's rarely used (!), like the runtime support for the "time" macro
elsewhere.  By moving it to "internal", it clearly signals to users
that they should not rely on the procedure directly.

The idea would be to have all the stuff that's not supposed to be
used into "internal".

Regarding time specifically, there are not many stand-alone programs
that will use this macro, I think.  It's more a thing for benchmarks
and such, so I'm not even sure it must be part of library.  It probably
was in there because the macro was in the "chicken" module.  There's a
lot of stuff that's much less optional than "time" (as in, used by day
to day programs) that lives in other units like file.scm.

> 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.

Please do.  We can argue about where to put the support stuff later :)


Attachment: signature.asc
Description: Digital signature

reply via email to

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