Re: [Chicken-hackers] [PATCH] Fix #1133

[Oleg Kolosov]

On 06/19/14 23:27, Peter Bex wrote:
> On Thu, Jun 19, 2014 at 09:13:01PM +0200, Felix Winkelmann wrote:
>> A few remarks:
>> - Modules are a namespace-specific concept, units are a
>>   loading/linking concept. Are you really comparing these here?
> 
> Well, kind of.  Let me tip-toe around the definitions to clarify:
> Currently units are used in core to define dependencies, which is one
> of the things that modules are used for as well. And as we saw in
> this ticket and the other one there are some problems which can be
> detected in dependencies expressed as modules but not when using
> "just units".

Units are also used for separate compilation of large code bases. It is
not always make sense to separate everything into modules. This is
useful, but should be build only matter. AFAIK, current system does not
allow to transparently switch between module and unit mode for the given
source file. We can try to add an option for chicken to mostly ignore
module declarations and just issue some useful warnings but compile as a
unit. This approach will enable incremental migration.

This might require huge refactoring of the current module handling
facilities. Which might be a good or bad thing depending on the point of
view.

>> - The possibility of static linking needs to be preserved.
> 
> I agree completely, and said as much in my email.

This area definitely needs attention. Especially handling of external
extensions (eggs). Last time I've tried to build completely static
binary it required adjustments to an eggs source code. I don't remember
specific details, maybe it is already improved. An ability to split up
the Chicken runtime might will be helpful, currently it is too big and
contains many unnecessary things (can be moved into eggs). Windows
support is nice to have, but too alien for current Chicken toolchain.
Also, seamless compiling for Android and iOS is a big deal.

>> - The module system is currently optional - one can just use core
>>   procedures in a toplevel program without using modules at all.  The
>>   machinery to make this work is admittedly ugly, but still I consider
>>   it a feature. Forcing pervasive use of modules is noit by itself a
>>   bad thing, but need to be thought out thoroughly.
> 
> Yes, this is a concern.  I think it may be possible to hook the unit
> system into the module system somehow (or vice versa), but you're right
> in that this won't "just work".

What do you think about Chibi Scheme approach
(http://synthcode.com/scheme/chibi/#h2_ModuleSystem)? Providing module
definitions separately, avoids aforementioned issues nicely, and,
coupled with an option to ignore everything as proposed above will allow
incremental migration. Also, having compatible (and standard compliant)
module system is a huge selling point IMO.

>> - It's possible that I misunderstand your intentions, considering the
>>   many meanings of the word "module" used in this context. But another
>>   issue that comes to mind is bootstrapping: if you change the
>>   imports/exports of a module that represents a core library unit, how
>>   can we prevent screw-ups due to mixing up of the
>>   import/export-information (import libraries) between the chicken
>>   that compiles and the chicken that is compiled? This can get very
>>   tricky.
> 
> Indeed, bootstrapping is an ever-present pitfall.  And there's also
> library.scm which does not really correspond to a particular module.
> Perhaps to "scheme", but not exactly.

I have not dived into this too deeply yet, but can you elaborate what
real problems you anticipate? Maybe someone could share an experience on
how other Scheme implementations handle this?

> I just wanted to put the idea out there, as a sort of "call to arms".
> This is another large-scale project that will take a lot of energy which
> I personally don't have right now.  Maybe I'll put it on the wish-list
> for a long-term goal.

We recently migrated our project to modules precisely for a reason
started this thread and still cleaning up the mess. Suddenly, we
realized that many files are placed in wrong folders, some parts have
circular dependencies, some know way too much about others. But seeing
this on the surface is a good thing in the end.

IMO, Chicken have some of these problems too, it is often hard to
predict which module has which function due to responsibilities mixed
between library, posix, files, extras, utils, et al.

First of all, I suggest to break things up into very small modules based
on intended usage and common sense (see R7RS or Chibi for examples) and
provide reexporting declarations for compatibility. This will allow to
freely move things around. Then refactor, cleanup, repeat.

I am very interested in this undertaking and want to help you out.

-- 
Regards, Oleg