Changeset 31269 in project


Ignore:
Timestamp:
08/23/14 17:27:26 (5 years ago)
Author:
sjamaan
Message:

Add a small proposal of naming for modules

File:
1 edited

Legend:

Unmodified
Added
Removed
  • wiki/chicken-5-roadmap

    r31268 r31269  
    3232"scheme" module to import all of the underlying submodules.
    3333
     34==== Replacing SRFI-14 with cset implementation from irregex?
     35
     36This has been discussed ages ago.  It might be more memory-friendly
     37and performant.  One problem with the current SRFI-14 module is that
     38it assumes Latin1 encoding (and therefore can only handle 256
     39different characters), whereas most other CHICKEN components and eggs
     40assume UTF-8.
     41
     42==== Refactoring the CHICKEN test suite to use a core library?
     43
     44As we remove a lot of cruft from core which it doesn't need, it may be
     45a good idea to add some things that we ''do'' need.  Like the {{test}}
     46egg: there is a lot of macro code duplication in core's test suite.
     47It's probably better to ship a well-designed testing library with
     48core, which core itself can also use.  This would make it easier, if
     49we decide to do this later, to format test output on Salmonella in a
     50consistent manner for both core and eggs.
     51
     52==== Proposed libraries
     53
     54Let's follow R7RS for these:
     55
     56* scheme.base
     57* scheme.case-lambda
     58* scheme.char
     59* scheme.complex (when numbers is integrated)
     60* scheme.cxr
     61* scheme.eval
     62* scheme.file
     63* scheme.inexact
     64* scheme.lazy
     65* scheme.load
     66* scheme.process-context
     67* scheme.read
     68* scheme.repl
     69* scheme.time (need this? want this?)
     70* scheme.write
     71
     72What will we do with the SRFIs we implement?  It would make sense to
     73define the following, but it would be tedious to import all these:
     74
     75; srfi-2 : and-let*
     76; srfi-8 : receive
     77; srfi-31 : rec
     78; srfi-26 : cut, cute
     79; srfi-15 : fluid-let
     80; srfi-17 : setter, getter-with-setter
     81; srfi-10 : define-reader-ctor
     82
     83Also, is it {{srfi-2}} or {{srfi.2}}?  The latter would match up with
     84{{(srfi 2)}} usage which is reserved by R7RS for SRFIs.
     85
     86The list below is just a proposal, can be changed at any time.  We
     87should also keep an eye on R7RS WG2, which may define a few things
     88CHICKEN currently defines already.
     89
     90; chicken.modules : module, import, export, reexport, define-interface, module-environment, functor, use
     91; chicken.types : {{:}}, the, assume, define-type, define-specialization, compiler-typecase
     92; chicken.reader-extensions : set-read-syntax!, set-sharp-read-syntax!, set-parameterized-read-syntax!, copy-read-table, current-read-table (perhaps re-export define-reader-ctor?)
     93; chicken.fx (or chicken.fixnum?) : fx+, fx-, fx/, fx*, fx<, fx<=, fx=, fx>, fx>=, fxand, fxeven?, fxior, fxmax, fxmin, fxmod, fxneg, fxnot, fxodd?, fxshl, fxshr, fxxor, fixnum-bits(?), fixnum-precision, fixnum?
     94; chicken.syntax : er-macro-transformer, ir-macro-transformer, gensym(?), expand (is this useful at all?), get-line-number, strip-syntax.
     95; chicken.bitwise : the subset of srfi-60 we support: bit-set?, bitwise-and, bitwise-not, bitwise-ior, bitwise-xor.  Possibly complete it with the remaining operations, and call it just "srfi-60"?
     96; chicken.ports : The current stuff in ports, except for the string ports in scheme.base (also, see below).  Perhaps get rid of port-fold, copy-port, port, map, port-for-each?
     97; chicken.exceptions (or srfi-12?  Would make more sense, but what about our extensions?  Put those in chicken.srfi-12?) : All the exception handling stuff.
     98; chicken.load : If we want to keep them, load-noisily, load-relative, load-library
     99; chicken.format : {{[fs]?printf}}, format (do we need this?), pp, pretty-print, pretty-print-width
     100
     101==== Proposed removal from core
     102
     103The list below is just one hacker's idea of what could go.  Please add more.
     104
     105===== SRFIs
     106
     107SRFI-1, SRFI-13, SRFI-14, SRFI-18 might be removed. SRFI-69 will be
     108removed, as discussed in CR #1142.
     109
     110===== queue datatype (data-structures), binary-search (data-structures), mmapped files (posix), object-evict (lolevel)
     111
     112Proposal already accepted in CR #1142.
     113
     114===== combinators
     115
     116Some of the combinators from data-structures are very nice, but there
     117only a handful of them are actually useful.  There is no technical
     118reason to keep them in core, they might fit better in an egg.
     119
     120===== Various ill-conceived POSIX things
     121
     122These things I don't like, but doesn't mean it *has* to go.  It may
     123always be put in an egg of course.
     124
     125* file-select (but see the next section!)
     126* file-control (no need to be in core)
     127* file-mkstemp (too tricky to use properly? maybe a different API)
     128* file-read and file-write (too low-level)
     129* file-stat (might be changed return a record type?)
     130* set-file-position! (see the section on I/O refactoring)
     131* All the time stuff.  It's too broken/difficult to use, and might be better off in an egg.  Core uses some of it, so we may need to reconsider and just improve the API.
     132* terminal-name, terminal-port?, terminal-size (but chicken-status uses it!)
     133* The process-stuff.  There are too many procedures which is confusing.  Boil it down to just one or two essential ones.  Possibly make a "fork&exec" implementation, which maps better to the Windows model, and still works fine on UNIX.
     134
     135=== Reworking the way libraries are loaded
     136
     137Right now there are just too many confusing things, like require, require-extension, use, import, load, load-library, require-library.
     138
     139Units and modules are confusing also.  This could just be a
     140documentation issue.
     141
     142=== Refactoring the scheduler
     143
     144One missing ability in the scheduler is for threads to block on more
     145than one object.  This would allow us to generalise {{file-select}} to
     146ports.
     147
     148===== Better API for continuations
     149
     150Nobody seems to use the "better API for continuations" by Feeley:
     151continuation-graft, continuation-capture, continuation-return,
     152continuation?
     153
     154If it doesn't benefit anyone (core doesn't use it, only two eggs do:
     155shift-reset and continuations), it can be taken out.  It might be put
     156into an egg.
     157
    34158=== Refactoring the I/O (ports) system
    35159
     
    74198If we go full Unicode, the SRFI-4/blob types might need some
    75199attention, because strings can no longer be (ab)used as byte vectors.
     200
     201=== Rewrite chicken-install and make setup-files declarative
     202
     203This will make it easier to make eggs statically compilable,
     204cross-compile them and perhaps integrate them into other build
     205systems.  It will also mean that setup-files won't be running
     206arbitrary Scheme code as root, which means it's more trustworthy.
     207
     208Another thing we need is to make files installed by eggs more
     209explicitly registered: currently "chicken-uninstall" will simply
     210remove all libraries that have the given name as a prefix.
Note: See TracChangeset for help on using the changeset viewer.