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

[Peter Bex]

On Fri, Jun 27, 2014 at 11:10:39PM +0400, Oleg Kolosov wrote:
> On 06/26/14 16:33, Peter Bex wrote:
> 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.

That's a good idea and will make conversion to true modules much simpler.

> > 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".

Indeed, but we must remain focused too.  Felix's mail convinced me that
first removing more things from core might make conversion to modules
easier, so I guess this is not an unrelated project, but more of a
prerequisite of converting to modules.

> 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.

Being able to pick and choose what parts from core you want is nice,
and will indeed help making it simpler to make specialised smaller
builds on embedded devices.

> > 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.

I'm not convinced we need separate loading and importing either, as long
as it doesn't interfere with separate compilation.  Right now everyone
always ends up doing (use ...) anyway.  Perhaps Felix can show us an
example where only an import (no loading of code) is useful, or otherwise
how I'm missing the point?

> 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?

I have no thoughts on this right now.  It could be a good idea, but
I'm unable to foresee the consequences.

Cheers,
Peter
-- 
http://www.more-magic.net