unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Nala Ginrut <nalaginrut@gmail.com>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel@gnu.org
Subject: Re: My Guile TODO list
Date: Fri, 9 Mar 2012 16:29:55 +0800	[thread overview]
Message-ID: <CAPjoZodWb-XBdaebueEHAOOKLBx6RTqxrCd9uXN105NSKXfTCA@mail.gmail.com> (raw)
In-Reply-To: <87zkbsur0l.fsf@netris.org>

[-- Attachment #1: Type: text/plain, Size: 12011 bytes --]

well, I think the real worth of this TODO list is, I don't bother to think
what can I do for Guile. I can steal some of them and go for it before you
done it. ;-)


On Thu, Mar 8, 2012 at 3:53 AM, Mark H Weaver <mhw@netris.org> wrote:

> Hello all,
>
> I occasionally talk about my large Guile TODO list, and sometimes people
> say that I should put it somewhere public.  Okay, here it is (not
> including my ticked messages in Gnus).  It includes some items that are
> probably controversial, especially near the end, and I'd rather not get
> stuck in huge threads about those ideas right now, so please just take
> this for what it is: a place where I record tentative ideas so they
> won't be forgotten.  Honestly, I'll be lucky if I find time to do a
> small fraction of this stuff :)
>
>    Best,
>     Mark
>
>
> Guile TODO
> ==========
>
> * Refactor pending numerics patches (Improved rationals et al)
>  (This will help Neils Möller with his minigmp project.)
>
> * Get rid of all of those 'resolve-module' and 'resolve-interface' calls
>  in hot procedures of (language elisp runtime)! (master)
>
> * Optimize important elisp primitives (master)
>
> * VM instruction to lisp canonicalize (#f or '() => #nil) ?
>
> * How to modularize libunicode?
>
> * Fix the warning system
>
> * Add call/ec to stable-2.0
>
> * Make call/ec as fast as possible in master (VM instruction?)
>
> * Allow the ,d REPL command to work for syntactic keywords
>
> * Improve (ice-9 match) documentation.
>
> * [SUBMITTED] Faster gensym: postpone giving it a name until requested.
>
> * Optimize exact-integer-sqrt: use floating-point for integers less than
>  2^53 (I learned that this is reliable from Shiro Kawai of Gauche)
>  (Related idea: use floating-point for some larger subset of the
>  rationals.  When is it safe to trust the result?)
>
> * Improve the implementations of map, for-each, et al.
>
> * How to modularize the numerics code?
> * How to implement the numerics operation dispatchers?
>  Best answer: Use GOOPS + FFI for GMP/MPFR/MPC; if not fast, fix it.
>  Practical answer: ?
>
> * Look into this:
>   UNRESOLVED: r6rs-arithmetic-fixnums.test: fx+/carry: simple
>   UNRESOLVED: r6rs-arithmetic-fixnums.test: fx-/carry: simple
>   UNRESOLVED: r6rs-arithmetic-fixnums.test: fx*/carry: simple
>
> * R7RS compliance
>   * optional ellipsis specifier for syntax-rules et al
>   * 'syntax-error'
>   * define-values
>   * let-values and let*-values (without loading SRFI-11)
>   * include-ci
>   * bytevectors in core R7RS
>   * lazy and eager (without loading SRFI-45)
>   * |...| symbol notation, and \xXX within symbols
>   * support #\escape and "\escape"
>   * support \xXXXX in string literals
>   * allow whitespace between \ and newline in string literals
>   * #!fold-case and #!no-fold-case
>   * #true and #false
>   * datum labels for circular and shared substructures
>   * nan? and finite? now accept complex numbers
>     (should probably change inf? and infinite? as well)
>   * exact-integer?
>   * R7RS exceptions
>   * make sure define-record-type is R7RS compliant
>   * optional third parameter to 'member' and 'assoc'
>   * define-library
>   * digit-value
>   * char-foldcase
>   * string-ni=? et al
>   * vector->string and string->vector
>   * vector-copy supports optional (start end fill) args
>   * vector-fill! supports optional (start end) args
>   * bytevector-copy! with 3 args
>   * bytevector-copy-partial{,!}
>   * write bytevectors with #u8 (and elements in hex) by default?
>   * {map,for-each} stops when shortest list runs out
>   * string-{map,for-each} accepts multiple strings
>   * vector-{map,for-each}
>   * make sure {map,vector-map,string-map} are multi-return safe
>   * {scheme-report,null}-environment for R7RS
>   * 'environment'
>   * 'port-open?'
>   * R7RS binary ports and bytevector ports
>      * {textual,binary}-port?
>      * open-binary-{input,output}-file
>      * open-{input,output}-bytevector
>      * get-output-bytevector
>      * {read,peek,write}-u8, u8-ready?
>      * read-bytevector{,!}
>      * write-bytevector
>      * write-partial-bytevector
>   * read-line
>   * write-simple
>   * flush-output-port
>   * load with optional 'environment specifier' as second argument
>   * get-environment-variable{,s}
>   * current-{second,jiffy}, jiffies-per-second
>   * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>     ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>     freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>     lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>
> * catch and raise in terms of R7RS/R6RS exceptions/conditions
>
> * compile-time dependency tracking for .go files
>
> * Good implementation of empty case-lambdas
>
> * Track down bytevector test failures reported by Hans Aberg
>
> * Add test cases:
>    string mutation test case (segfaults on earlier versions)
>    attempt to mutate empty range of immutable string
>    narrow substring of wide string should be narrow
>    empty substring should not hold reference to original stringbuf
>    newly allocated empty strings share a common null stringbuf
>    make sure multiple copies of the empty string are distinct
>      from C
>      from Scheme
>
> * Improve the hash function, and allow GOOPS objects et al to
>  declare their own custom hash function.
>
> * Improve the PRNG and its initializer
>
> * Improve ice-9/format
>   * truncate/ <= quotient and remainder [DONE but not committed]
>   * Exact numbers in positional-number system without imprecision
>
> * Add missing documentation for several interfaces in foreign.c
>
> * Consistently validate that indices are _exact_ integers.
>  (XXX maybe already done?)
>
> * Consistently enforce the immutability or literals (lists, vectors,
>  strings, syntax, and ideally in primitive-eval as well)
>
> * Top-level identifiers introduced by macros should be hygienic
>
> * (?) investigate the feasibility of making 'equal?' and 'eqv?' as fast
>  as 'eq?' when at least one of two arguments is immediate-or-interned,
>  by making it easy to determine from the bit pattern of the SCM value
>  itself whether the value is immediate-or-interned.  This would require
>  changing the representation of symbols and keywords to immediate
>  values (containing an index into a table).
>
> * Numerics improvements:
>   * Add scheme-accessible frexp and ldexp procedures
>   * Add exact-integer? predicate
>   * exact-integer-root with remainder
>   * Exact 'expt' to rational power when the result is rational
>   * Exact log-floor, log10(?), and log2(?) (or arbitrary base)
>   * Deprecate low-level numeric predicates in 2.2
>   * Improved modularity
>   * Extensible numerics with GOOPS
>   * Arbitrary-precision floats in Scheme with GOOPS
>   * Complex numbers with general real components
>   * Infinite-precision reals (maybe continued fractions/logs)
>   * Scmutils for Guile 2
>   * Modular MPFR/MPC support
>
> * Filesystem paths as sequences of path components (et al)
>
> * Strings overhaul
>
>  * Decide on strategy for POSIX byte strings
>     * Decide on implementation
>        * Distinct low-level type
>          (implied by strings-as-views-of-bytevectors/bytestrings)
>        * UTF-8 with special range of codepoints
>     * Decide on semantics
>        * (bytestring? x) implies (string? x)
>        * (bytestring? x) or (string? x) implies (generalized-string? x)
>
>   * Strings as views of bytevectors (UTF-8 or POSIX byte strings)
>      Note that bytevectors can use any range of aligned(?) memory,
>        with no inline header or footer, in the middle of some
>        arbitrary 'parent' block.  (Thanks, Andy! :)
>
>   * UTF-8 backed strings, while allowing (external?) code to easily
>     work in terms of bytes instead of characters
>
>   * (?) Immutable strings built by snapshotting a mutable string,
>     (to allow the user to dynamically create an immutable string
>     that supports efficient append et al)
>
>   * (?) Mutable strings as mutable pointers to immutable strings
>
>   * (?) Efficient data structure for large strings (and similarly for
>         bytevectors/bytestrings)
>
> * Allow 'with-{input-from,output-to}-file' et al to accept file open
>  modes, e.g. encoding=?, binary, create, append, truncate, etc.
>
> * (ice-9 popen) overhaul
>   * Support closing output side of pipe before closing input side
>   * (?) Maybe honor current-{input,output,error}-port settings
>   * (?) Integrate more features (maybe from Scsh)
>
> * Ports overhaul
>   * (?) Remove scm_t_port from the ABI
>   * Character ports as views of byte ports
>     (maybe allow interleaved byte/char access)
>   * Bytevector ports
>   * Efficient soft ports
>
> * Chunked encoding for web client
>
> * Sweet expressions
>
> * Gnulib-style layer shipped with applications to allow use of Guile 2
>  APIs with transparent 1.8 compatibility
>   * (Ideally) get modules accepted into Gnulib itself
>
> * New bracket pairs (maybe allow user to define them),
>  maybe reduced to macro calls,
>  e.g. {a b c} => (within-curly-brackets a b c)
>
> * Parser combinators a.l.a. Haskell
>
> * Efficient purely-functional data structures,
>  like Chris Okasaki's Edison, for Guile
>
> * Monad library?
>
> * Improve error messages and debugging
>   * Improve error messages, searching for bad messages
>   * Learn from MIT/GNU Scheme
>   * Improve backtraces and debugging
>      * History rings for tail calls
>      * Display in 'current subproblem' form
>      * (?) Continuation as a psuedo-expression with a hole
>
> * Improve evaluator
>   * (?) Just use compiler with most optimizations disabled?
>   * Improve error messages
>   * Improve debugging
>
> * Plotting software using guile-cairo
>
> Big picture items
> =================
>
> * (?) unexec
>
> * Register-based VM
>
> * Improved modularity
>
> * Translate as much C code as possible to Scheme.
>
> * Move as much as possible into a shared read-only segment of libguile
>   * Purge as much *_init activity as possible
>   * Transition to auto-generated C files with statically initialized data
>     structures (i.e. enhance Snarfing)
>
> * Numbers overhaul
>   * Improved modularity; allow a minimal core
>   * Make GOOPS fast enough that it can replace hand-optimized C
>     dispatchers in numbers.c
>   * Support and implement many advanced arithmetic objects
>      * Abstract algebra: Rings, Commutative Rings, Fields, etc.
>      * Arbitrary-precision floating-point (with unbounded exponent)
>      * MPFR
>      * Infinite-precision reals (e.g. continued fractions/logs)
>      * Exact arithmetic numbers
>      * Exact irrationals (some useful subset)
>         (?) maybe just use symbolic expressions here
>      * Real Intervals
>      * Complex numbers with arbitrary rectangular coordinates
>        (e.g. exact rationals)
>      * MPC
>      * Quaternions
>      * Vectors
>      * Matrices
>      * Polynomials
>      * Symbolic expressions based on lexical scoping and
>        syntax-objects
>
> * Switch most Scheme primitives to use our own calling convention, and
>  provide (optional) auto-generated wrappers that use the standard C
>  calling convention.
>
> * Compiler overhaul
>   * Immutable (or rarely mutated) top-level bindings
>   * Immutable pairs?
>   * Tracing and hotspots drive the incremental optimizer
>
> * FFI overhaul
>   * Native code generation where possible, else generated C code
>   * Fast enough so that it could be our only link to C, and can be used
>     to wrap all scm_*, allowing all of the C sources to be more nicely
>     written, and supporting automatic type checking.
>
>

[-- Attachment #2: Type: text/html, Size: 13552 bytes --]

  parent reply	other threads:[~2012-03-09  8:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07 19:53 My Guile TODO list Mark H Weaver
2012-03-07 20:20 ` Andy Wingo
2012-03-09 19:01   ` Mark H Weaver
2012-03-07 20:26 ` David Kastrup
2012-03-07 22:31 ` Ludovic Courtès
2012-03-09 19:07   ` Mark H Weaver
2012-03-10 22:13     ` Ludovic Courtès
2012-03-09  8:29 ` Nala Ginrut [this message]
2012-03-09 14:53   ` Mark H Weaver
2012-03-10 22:49 ` Ian Price
2012-03-16 11:14   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPjoZodWb-XBdaebueEHAOOKLBx6RTqxrCd9uXN105NSKXfTCA@mail.gmail.com \
    --to=nalaginrut@gmail.com \
    --cc=guile-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).