chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Sat, 28 Jun 2014 12:02:34 +0200
User-agent: Mutt/1.4.2.3i

On Fri, Jun 27, 2014 at 04:41:07PM +0200, Felix Winkelmann wrote:
> 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? 

Quite a lot, but it's a large project that is not exactly well-defined.
And the backwards compatibility will be pretty tricky too.  However, I
think we can easily get started with removing stuff from core that isn't
used at all (like the mmapped files, and srfis).  Once the core has been
made smaller, it will be easier to move things around and refactor what's
left.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]