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

[Oleg Kolosov]

On 06/26/14 16:33, Peter Bex wrote:
> On Mon, Jun 23, 2014 at 04:02:59AM +0400, Oleg Kolosov wrote:
>> On 06/19/14 23:27, Peter Bex wrote:
>> 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.
> 
> That's an interesting idea.  It might work, but I'm also unsure of the
> added benefit; if the code is always compiled separately in the "ignore
> modules" mode, it won't add the intended benefits of additional checking
> of dependencies and exports.

I mean an option to compile like: internally convert (module <name>
<exports>) to (declare <name>), hook import somehow into this for rename
and such, issue warnings for names still unresolved but just continue
and generate a unit. This will allow having something working during
conversion to modules and not require to declare and resolve everything
at once. This is all hand wavy, I have not investigated technical
details too much, but it seemed not so hard to do at first sight.

>> ...cific 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 ...
> 
> I'm unsure how much further we can strip down the core.  Perhaps we can
> drop SRFI-1, SRFI-13 and SRFI-14, which would be just fine as eggs.  But
> currently core is using some procedures from these.  I think that this is
> a separate issue, though.  Refactoring stuff as modules is a shitload of
> work which is not yet certain to be feasible, and we should not drag more
> work into this project.

Eggs was not the right word. I meant to just split it up more and make
most components optional. I was under an impression somehow that this
was the point of "call to arms".

The motivation here is that we found out that Chicken works surprisingly
well on embedded devices and want to integrate it even deeper (like
initramfs, firmware updater and such). An experiments show it is
possible to reduce runtime size to at least half of it's current size
and still have something usable. But it is too troublesome to do
manually, modularization will definitely help here and looks like good
thing in general.

>> What do you think about Chibi Scheme approach
>> (http://synthcode.com/scheme/chibi/#h2_ModuleSystem)?
>> Also, having compatible (and standard compliant)
>> module system is a huge selling point IMO.
> 
> We already support this syntax through the R7RS egg.  We can't just
> switch to the R7RS module system in core because it would break 100% of
> the user code out there, for no technical gain whatsoever.  CHICKEN core
> is an R5RS system, and adding an R7RS module system to it adds no
> benefit if everything else from R7RS is only available as an extension.
> 
> We have already too many people asking about the difference between use,
> require, require-extension, uses etc.  Adding a second module system to
> core would only add to the confusion (and *replacing* it would break the
> world).

The idea is: require and friends are not necessary at all (and
confusing). The user should just use import and let the runtime system
figure it out. Like John mentioned earlier.

The only real use case for detailed control over library loading I can
imagine is the support for module hot reload.

>>> 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.
> 
> Yeah.  Especially the stuff from posix should be cleaned up.  There are
> plenty of things unrelated things in there at varying abstraction levels,
> which is only stuffed in there because it's somehow related to an
> underlying syscall that's defined by POSIX.  This is a little too
> system-specific for me; it would make more sense to group those things
> together into things like files, process-control, user-management etc,
> and define modules in that way.
> 

That got me thinking: maybe we could implement module versioning? Not
just put everything into lib/chicken/<API_VERSION> but proper
module.so.1.2.3 like other shared libraries? And somehow add this to
imported namespace (##module#1.2.3#procedure or so). In theory this
should allow to move stuff around, but can open a whole can of worms,
but still, what do you think?

-- 
Regards, Oleg