chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] CR #1142 and upcoming changes


From: Felix Winkelmann
Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
Date: Tue, 19 Aug 2014 17:21:06 +0200 (CEST)

>  I would think that support for Chicken 2 & 3 should be dropped after a
> Chicken 5 branch is made.

Yes, that sounds reasonable.

> I had also implicitly assumed that the modularisation changes would help
> bring full R7RS support to core.

I think it is R7RS support will be in an egg for the time being. Once
we figure out the remaining issues, this should be usable in a rather
seamless way.

> Is this not the case? What are the goals for a Chicken 5 release?

Mostly cleaning up. Shrinking the core system will make maintenance
easier, and reduces the need to follow our usual patch-review process.
It also allows to use alternatives to cast-in-concrete APIs (like
srfi-18) in an easier way. A smaller core system makes it also easier
to use it on embedded systems, in particular on systems that don't
need loads of external libraries.

Restructuring the libraries is required to make things easier for
users, especially newcomers. The current library structure is mostly
arbitrary.  This is not a problem for long-time users, but where what
procedure can be found is currently very unintuitive - one just has to
know about it, or use tools like chicken-doc all the time. 

Finally, using more modules in core catches many errors related to
wrong naming, or unintended cross-references between library units.

Oh, and should we ever want to have a fully "transparent" import that
always does The Right Thing, then a cleaned up and more modularized
core will be essential to that.

We really need to address the cruft that has accumulated over more
than a decade...


felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]