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

[Felix Winkelmann]

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

That might be a good idea. Some of the SRFI-procedures are more
general than we need.

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

The scheme module is created by hand, there is no file corresponding
to it. I would propose to keep as much as possible in "chicken", even
if there is file overlap. These internal modules do not map to
specific files anyway. This means basically all the stuff in
"modules", "expand", "library", "eval" and "chicken-syntax".

It's the library-units that need to be heavily restructured, I think.

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

Yes, I agree.

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

I would propose something like this:

- identify stuff that's not used in core and move that to eggs, for example:

  memory-mapped files
  binary-search (this screams out to be implemented as a functor)
  queues
  ... much more, of possible ...

- Completely restructure all library units (extras, data-structures, files,
  ports, lolevel, posix, utils). tcp and foreign stay as they are.

- irregex is used in core and will benefit from as much core-support as
  it can get, so leave it as it is, as well.

- re-implement/copy stuff from SRFI-1/13/14 for internal use only,
  move the rest into eggs.

- I would like to move srfi-18 to an egg as well, only keep the scheduler
  and the internal threading-stuff in library.scm in core.

- srfi-69 can go to an egg. It is only used in chicken-profile, and
  can be done using internal (symbol) hash-tables.

- I think srfi-4 can be eggified, too.

- Provide wrapper eggs for all the library units that are gone
  (extras, ports, files, data-structures).

- I'm not sure about posix. Perhaps split this into higher-level
  modules (eggify, if not needed in core) and keep a lower-level
  interface in core.

- Use modules for the compiler. It is not used externally (well,
  with the exception of user-passes, which nobody uses, I guess)
  and would need some restructuring as well. But this may be a
  first attempt at using modules internally.

Does this make sense? 


felix