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

[Peter Bex]

On Thu, Jun 26, 2014 at 03:56:47PM +0200, Felix Winkelmann wrote:
> 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.

Depending on how large the subset of procedures is we could perhaps pull
a simplified version of them into core and optimise that to hell, and
excise the slow remaining crap from core and move it to an egg (we
already have some duplication like foldl vs fold and string-intersperse
vs string-join).  But I'm really not sure, I'd have to investigate.

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

I've asked Seth and he said it's working adequately.  Maybe Evan can
provide us with some more in-depth info.

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

The ##-things and such.  If it's already exported by a module like
chicken or scheme that's fine.  But it might make more sense to put
it in scheme.scm in that case, if that's doable.  We'd probably have to
split up core a bit in order to avoid having an overlap between files
and modules like we do now (eg, eval.scm, module.scm and library.scm
define things that are exported by the chicken module, but other things
from library.scm are exported by the scheme module).

We could still keep eval.scm and module.scm for example, if they strictly
export things for chicken.  If that's undoable we could define lower-level
modules and compose the chicken and scheme modules from them, like it
more-or-less works right now.  This could be the simplest thing to start
out with, anyway.

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

Good to know, thanks for explaining.

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

At least we can steal some good designs from other Schemes and Lisps,
where appropriate. :)

The biggest problem I have is the different abstraction levels of the
"posix" unit.  Some are extremely thin wrappers (like for example
file-select and file-{open,read,write}, which block the entire process
instead of handling I/O in a nonblocking way and integrating with
the scheduler like the rest of the system does; file-read just returns
-1 and sets errno if you try to make it nonblocking), whereas others are
pretty sophisticated library procedures which provide a more high-level
API (like for example find-files and the signal handling stuff).

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

Hehehe, "somewhat" :)  But you're right, most of what POSIX offers is
valuable and needs to be deeply integrated in core in order to provide
good support so it makes sense.  Still, I like the idea of having only
completely portable stuff in core, so that programmers know that if it's
in core, it's going to work everywhere.  That can save a lot of headaches
when porting an application to Windows, or CHICKEN to a completely new
platform.

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