Re: [Chicken-hackers] (no subject)

[Peter Bex]

On Sun, Apr 09, 2017 at 09:01:16AM +0200, Kristian Lein-Mathisen wrote:
> Hello dear CHICKEN core members,
> 
> Here's my attempt at making a chicken.load module.

Hi Kristian,

Thanks for putting in some effort on CHICKEN 5!  I know this is tricky
stuff to work on, so I'm glad you're taking the time to figure all this
out.

Your patch adds a new unit file, which introduces its own toplevel.
We decided against that (for now, at least) because more toplevels
introduce more overhead, if I recall correctly.

In any case, if we do decide to move this to its own unit, the
actual definitions of the exported identifiers should move into that
file as well.  What your patch does is basically add a toplevel that's
empty, except for some set! calls that alias definitions from another
unit; eval.scm in this case, and then expose that as a module.

So while your patch basically fulfills the goal of the restructuring
the core libraries for the user, it doesn't make the core itself more
modular: it now has the definitions in eval.scm and the "official"
module in which the definitions reside in load.scm.  And, besides,
the chicken.eval module still _also_ exposes these definitions, which
is not what we want.

Can you rework the patch so that it moves the "load" definitions inside
eval.scm?  The goal is to have the definitions inside their own module,
chicken.load, instead of in chicken.eval?  One unit file can expose
multiple modules.  You can see examples of this in library.scm, search
for "(module".  There are chicken.time, chicken.fixnum, chicken.bitwise,
etc.

> It was fairly
> straight-forward, except I don't know what to do with the unit
> declaration regarding (fixnum) and (disable-interrrupts), so I copied
> file.scm's:
> 
> (declare
>   (unit load)
>   (uses eval)
>   (fixnum) ;; TODO: do we need (fixnum) here?
>   (disable-interrupts)) ;; TODO: do we need (disable-interrupts) here?

Because you don't need to make a new file, this is not necessary, but
since you're trying to grok more of core, I can try to explain what the
logic would be behind adding them or not.  In your patch, as-is, it
literally makes no difference if you include or exclude those
declarations, because there is no actual code in the unit, aside from
a few set! calls at toplevel.

The (declare fixnum) is kind of deprecated, because having only fixnum
and flonum modes makes less sense with a full numeric tower.  Still,
it has some use if you know you only want to use fixnums.  In this case,
I think it doesn't matter much because load wouldn't be doing much
fixnum-related operations.

I don't know if disable-interrupts is necessary or even desirable in
this case.  Probably it isn't, considering eval.scm does not have that
declaration either.  The disable-interrupts declaration should be
avoided as much as possible, because it will make a program
uninterruptible while code is running inside such a unit (so ^C won't
work, etc).  It does provide a (small) performance boost, and it can
be helpful against certain race conditions (that's why scheduler.scm
has this declaration, for example).

I hope my explanations are sufficient to clarify what we're trying to do
with this restructuring of the core libs.

Cheers,
Peter

signature.asc
Description: Digital signature