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
_______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
