Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Felix Winkelmann]

> 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