[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Fix #1133
From: |
Felix Winkelmann |
Subject: |
Re: [Chicken-hackers] [PATCH] Fix #1133 |
Date: |
Fri, 27 Jun 2014 16:41:07 +0200 (CEST) |
> 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
- Re: [Chicken-hackers] [PATCH] Fix #1133, (continued)
- Re: [Chicken-hackers] [PATCH] Fix #1133, Oleg Kolosov, 2014/06/22
- Re: [Chicken-hackers] [PATCH] Fix #1133, John Cowan, 2014/06/23
- Re: [Chicken-hackers] [PATCH] Fix #1133, Peter Bex, 2014/06/26
- Re: [Chicken-hackers] [PATCH] Fix #1133, Felix Winkelmann, 2014/06/26
- Re: [Chicken-hackers] [PATCH] Fix #1133, Peter Bex, 2014/06/26
- Re: [Chicken-hackers] [PATCH] Fix #1133, Evan Hanson, 2014/06/26
- Re: [Chicken-hackers] [PATCH] Fix #1133, John Cowan, 2014/06/26
- Re: [Chicken-hackers] [PATCH] Fix #1133, Felix Winkelmann, 2014/06/30
- Re: [Chicken-hackers] [PATCH] Fix #1133,
Felix Winkelmann <=
- Re: [Chicken-hackers] [PATCH] Fix #1133, Oleg Kolosov, 2014/06/27
- Re: [Chicken-hackers] [PATCH] Fix #1133, Felix Winkelmann, 2014/06/27
- Re: [Chicken-hackers] [PATCH] Fix #1133, Peter Bex, 2014/06/28
- Re: [Chicken-hackers] [PATCH] Fix #1133, Jörg F. Wittenberger, 2014/06/29
- Re: [Chicken-hackers] [PATCH] Fix #1133, Peter Bex, 2014/06/28
- Re: [Chicken-hackers] [PATCH] Fix #1133, John Cowan, 2014/06/26
- Re: [Chicken-hackers] [PATCH] Fix #1133, Oleg Kolosov, 2014/06/27
- Re: [Chicken-hackers] [PATCH] Fix #1133, Peter Bex, 2014/06/28
- Re: [Chicken-hackers] [PATCH] Fix #1133, Felix Winkelmann, 2014/06/28
- Re: [Chicken-hackers] [PATCH] Fix #1133, Peter Bex, 2014/06/29