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

[Felix Winkelmann]

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

The compiler and egg-setup stuff need a number of srfi-1/13/14
primitives, and the core tarball should be self-contained, so I see not
much chance to eggify more of the base system.

> We already support this syntax through the R7RS egg.  

BTW, what's the status of that egg? The last time I looked it seemed
to be basically complete. Or is there still anything missing? (I know
there are some rough edges, and obscure warnings, but does it
basically work?)

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

(add1 from me...)

> The simple solution would be to stuff everything into a "core" module
> which nobody but the core system is supposed to really use.  We could
> then define r4rs and r5rs/scheme as modules which import the whole of
> core and reexport only the relevant procedures.

What you mean by "everything" here? All the ##this#.. and ##that#...,
or the non-standard chicken procedures that are usually exported from
the "chicken" module?

> 
> But there's still the problem of code which replaces primitive
> procedures.  However much this is frowned upon by "modern" Scheme
> standards, this is something that is explicitly allowed by RnRS | n < 6.
> AFAIK toplevel code can do that even with identifiers exported by egg
> modules, so perhaps this is not an issue.  We have to test it though, and
> luckily r4rstest.scm already checks this.

The module system doesn't prevent this, it just renames identifiers,
but doesn't change the semantics of assignment.

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

Be aware that a platform-independent layer over those syscalls is
quite some design work. There is a reason why so many library
implementations often fall back to doing exactly this: wrapping each
and every syscall (look at ocaml, or the SML basis library).

Take windows into the equation and things get even worse. POSIX is not
the most ideal API "standard", but at least it is something one can
start with, even if Windows support is somewhat painful.

> 
>> I am very interested in this undertaking and want to help you out.
> 
> That would be much appreciated, once we get started.

Indeed.


felix