I've made a start on the wiki, at what we'd like CHICKEN 5 to be about.
Please, do not make this into another pony page, only add things that
we really need to look at which require a rework in core which may be
backwards-incompatible.
Hello, Peter!
I generally agree with most proposed changes on this list (with the
exception of the idea to drop fluid-let, of course.) But it must be
clear to you that you already created a pony page. It is impossible
to do all of that, so before we go crazy with ideas, we should perhaps
get back to what we want to achieve with CHICKEN 5.
As I understand it, the idea is to decruftify (that is drop or eggify
library code), give proper names and modularize. This is all related
in one way or the other and looks like it can be done with the little
resources we have, especially considering that it will take ages until
only a reasonable subset of the existing eggs compiles and runs
properly in the new system.
* Designing a decent POSIX API is a hard task. I have not seen any
reasonably good API wrapper for that yet - they are either too
lowlevel (Basis, Ocaml, etc.), or too highlevel.
* Changing the string representation is much harder than you think
(quoting John: If Chibi can do it, so can we completely ignores
the fact that writing a string-representation implementation from
scratch is something vastly different than modifying an existing
one, one that is much older and much more widely used from
foreign/native code.)
* Numeric tower support: this is also hard, and will have a
considerable performance impact, needs changes in the compiler, in
all the icky C glue code and particularly in foreign code - which
means things will break all over the place in user code.
* Port-refactoring: again - basically a good idea, but tricky to
design, and may have a large performance impact, and the refactoring
will be work-intensive (all the direct peeking and poking in port
records needs to be localized and changed). This change should also
ideally be considered to be done in tandem with changing the string
representation.
* chicken-install/setup-files: a major and very important project on
its own. I started thinking about this some time ago, but didn't get
anywhere. Something very simple needs to be found that covers most
use cases, but this is something that needs input by many people
that have experience with the egg system and applicastions written
in CHICKEN. Perhaps we should plan to think about this the next time
some CHICKEN-hackers meet?
I _do_ think all the proposed changes make sense more or less, but
it's unrealistic to think that we achieve anything more than one or
two of the big parts.
A few more notes:
* I think John's idea of putting all the little SRFIs in a few (or a
single) module is better that splitting everything up into
modules. Having modules for each and everything looks nice on paper
but quickly gets old when you have to modify your module imports
every time you use a common but nonstandard language construct. I
understand that some people like this kind of bureaucracy, but
what's wrong with making things easier for the user?
* Please use long, explicit library names, it's easier to remember
(there are many ways to abbreviate something, but only one way not
to - I forgot who said this, John will tell me, I'm sure.) And I
would also suggest to avoid using srfi-XXX as a module name, and
to use something meaningful (yes, I know that in the past I was
largely responsible for that mistake in numerous situations.) That
would also allow adding our own extensions.
* I can't resist to add a pony on my own: I fear that integrating the
R7RS syntax-rules cleanly and transparently inside an egg will be
tricky. What about changing syntax-rules to have R7RS semantics in
general? I'm not sure if I understand the differences well enough,
perhaps someone (Peter?) can comment on this.
So, in short: forget about unicode, the full numeric tower,
chicken-install, port-refactoring and everything but modularization,
the internal structure (and size!) and the necessary issues of doing a
major release (e.g. the question of how to integrate that with
henrietta.)
The major problem is that re-modularization will be the biggest
barrier in migrating user code. Once that is done we have a groundwork
for the really tricky things, and for smaller API changes that are
easier to detect via the module system.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
