Re: [Chicken-hackers] too many core modules?

[Alex Shinn]

felix winkelmann <address@hidden> writes:

> It's probably just me, but if I have to write "(use ports files
> data-structures utils extras)" one more
> time, I'll go crazy.
>
> I think the splitting up of the extras unit was done haphazardly. It
> doesn't really give any
> benefit to split up the library fo chicken extensions, since loading
> one or two eggs will drag in
> most of them anyway. I think it's ok to keep the SRFIs separate.
>
> Therefore I'd like to introduce a new library unit (say
> "chicken-stuff" [*]) that for the time
> being just loads the other units and provides the necessary imports.
> Nothing else
> will be changed, with the exception of the manual. We can provide a 
> placeholder
> extension for pre 4.1.6 chickens (just like Mario did for the "files" unit).
>
> Is it ok to make this change, or does somebody see a problem with this?

What about generalising this to make it easy for other user
modules?

For example, PLT units or Scheme48 modules let you define
compound modules and other tricks.  These are very complex
module systems, but just aggregating a bunch of modules that
are used together is quite common, so that Gauche provides a
simple (extend <module-A>) form which is the same as (import
<module-A>) (export <module-A's-exports>).

Then if you have some framework like spiffy where people
repeatedly import the same modules, you can do

(module spiffy-framework
  (extend spiffy spiffy-utils spiffy-hacks spiffy-extras ...))

and everyone can use grab everything with

  (import spiffy-framework)

-- 
Alex