Re: [Chicken-hackers] [PATCH 0/1] Split eval.scm into chicken.eval and chicken.load modules

[Peter Bex]

On Tue, May 02, 2017 at 07:33:23PM +1200, Evan Hanson wrote:
> Hi folks,
> 
> Here's a patch that creates the "chicken.load" module per the roadmap.
> 
> It's mostly just reorganising code in eval.scm and doesn't yet hide
> `load` or `eval` from their respective modules, but it's a step. I tried
> to find a way to move things around that kept the diff reasonably small.
> Please see the commit message for a description.

Nice, I've pushed this.  I noticed that we still have "eval-handler",
which wasn't in core-libraries-reorg AFAIK.  I guess we need to keep
that, and the only place that makes any sense for this would be in a
"chicken.eval" module.

If we decide to keep a module like that after all, it makes less sense
to have only one export.  So let's make eval/meta an official API.  It
is a clean API that doesn't need to be internal/hidden at all; it could
make sense for user code.  This allows us to get rid of another ##sys#
prefix.

If accepted, I'll re-add (chicken eval) to the core-libraries-reorg
wiki page.

I also moved the things from "scheme" to a separate line, so we get
reminded and know what to do with it.  I think what we discussed on
IRC would probably work:  Move (module scheme) to library.scm with
lots of exports, but mostly empty definitions.  Then we can set! to
it in other modules, like chicken.eval and chicken.load.  This also
takes care of dependencies: we define all the stubs first, then load
dependencies and finally override the stubs with actual implementations.

I hope to make that patch soon.

Cheers,
Peter

0001-Promote-eval-meta-to-an-official-API-and-make-chicke.patch
Description: Text Data

signature.asc
Description: Digital signature