Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!gatech!newsfeed.pitt.edu!uunet!news.cygnus.com!nntp!lord
From: lord@cygnus.com (Tom Lord)
Subject: GEL Task List (the GNU Extension Language)
Message-ID: <LORD.94Nov3163556@cygnus.com>
Followup-To: poster
Sender: news@cygnus.com
Nntp-Posting-Host: cygnus.com
Organization: Cygnus Support
Date: Fri, 4 Nov 1994 00:35:56 GMT
Lines: 189


Readers of comp.lang.scheme: Please be fair to that newsgroup and
mailing list by not debating this task list there.  I will try to post
responses to some of the criticisms that have been raised so far; but
i will stop doing so if the result is to flood comp.lang.scheme with
too many unwelcome posts.  If you want to effect the project constructively,
write to me directly.  



			  THE GEL TASK LIST

Here is the list of GEL tasks.  Associated with these tasks are design
specifications, some of which have been written, and some of which are
works in progress.  We intend to focus the design specification
process using demand-driven scheduling (that is, we'll work on
whatever documents people are waiting for next).

To sign up for a task, write to lord@gnu.ai.mit.edu and state what
task you are interested in doing.  I'll try to resolve conflicts,
connect teams together, and make sure that all of the most important
tasks are covered.  Aubrey Jaffer will be merging modifications back
into the distribution.


The items in this list are stated very briefly.  It isn't expected
that you can read just the information in this list and begin working
on the task immediately.  It is important to write in before starting
work so that we can make sure the overall design requirements are met.

The first item in the task list is special.  In concerns the interface
between the core interpreter and C programs and extensions generally.
This task is special because it effects most of the others.  It is
also special because it establishes permenant constraints on the
implementation of the core interpreter.

Task 0 is where, at this time, the design specification effort is
focused.  Next week we will post a draft specification of our
interface to C.  The draft will be posted to comp.lang.scheme and to
the gel mailing list.

It is *not* necessary to wait for the completion of task 0 before
working on the other tasks.  Although we expect the interface to C to
change, it will not be hard to modify code written for the current SCM
to C interface to fit the new interface.  So by all means, feel free
to grab SCM and sign up for specific tasks.



0: C friendliness

  - Rename all macros, extern symbols, and types in SCM to use a consistent
    and clean naming convention.

  - Make a shell script that can be run over existing SCM extensions
    and that will fix ``90%'' of the symbol renamings.  This is only
    to help people port their SCM extensions quickly to modified SCM.

  - Implement the new interface for declaring and defining built-in functions.

A: multiple obarrays

   - multiple obarrays are a way to have disjoint universes of symbols
	In other words, using multiple obarrays, you can intern the same
	name twice (in different obarrays) and obtain different symbols
	which are not eq?.

B: a module or package system

   - this is not the same thing as multiple obarrays.

C: fast exception handling

   - make a fast, safe, downward only variation on call/cc

   - implement catch and throw using call/downward-continuation.

D: documentation

   - starting from the design specification documents.

E: a rich set of string manipulation built-ins

F: lifeguards

   - Lifeguards are similar to guardians -- they are used to help
     with the finalization of data structures (i.e., they 
     relate to garbage collection).

G: C-like syntax

   - The goal is to make this just as useful as Scheme syntax for 
     extending programs that use GEL (including the GEL run-time)

H: a debugger

   - Both a programmatic and a user interface are needed.

I: elisp built-ins (the lisp built-ins, not necessarily the Emacs built-ins)

J: SCSH features

K: [*] A safe execution environment

L: Dynamic binding primitives

   - These are not necessarily for use from Scheme.  They are needed
     for an efficient translation of elisp.

M: Tcl-style C callouts

   - A least common denominator, string based system of C callouts.

N: [*] Stackless eval

   - Versions of eval and the built-ins that call eval that don't
     use the C stack to hold their state.  These are useful for
     the sake of: fast call/cc, precise garbage collection, 
     Scheme threads, and the externalization of continuations.

O: [*] efficient threads in Scheme
   - Support first for cooperative, then preemptive threads.

P: [*] Incremental GC

   - Probably an incremental mark/sweep algorithm.

Q: Expect functionality

   - Bindings for the library version of expect are useful. 
     There may be overlap between expect and the features of SCSH.

R: [*] relax

S: [*] Externalization of arbitrary Scheme data

   - Many Scheme types when printed produce representations that
     can be read.  For those types, print and read implement a 
     two stage deep copy.  The GEL printer should extend this capability
     to all built-in types, and to as many extension types as is practical.

T: Modifications to bison for making parsers in Scheme.

   - Bison can be modified to generate Scheme code instead of C.
     Doing so will make it easier to implement the C-like syntax as
     well as other interesting syntaxes.

U: A Rush or shell-like syntax, especially for SCSH

   - The SCSH project is said to already have a design for this.

V: Posix bindings

   - Most of these have recently been added to SCM.  The goal here will
     be to integrate them with GEL's exception handling conventions.

W: elisp->Scheme translation

   - this task is to implement the language translation, but not yet
     the Emacs run-time.

X: Modifications to Rx so that it can be used as a lexer.
   -or- Modifications to flex so that it can generate Scheme code.

   - In short, we want dynamicly loadable lexers.

Y: Tk bindings

   - If there is enough support from volunteers, we can Do The Right Thing
     by not using the string based interface to Tk.  If we do a very
     clean job of this, then there is a chance that our improvements will
     be accepted back into the mainstream Tk distribution.

   - It would be nice to learn from and borrow code from Stk.

Z: [*] Low level graphics bindings

   - As part of the extension of Tk, we should make it possible to do
     more graphics programming in GEL, and less in C.

AA: A port of the Emacs run-time to GEL.
AB: [*] A Mosaic-type web interface (with mozilla-style connection mgt.)
AC: [*] Hooks into MIME

--
----

If you would like to volunteer to help with the GNU extension language
project, please write to lord@gnu.ai.mit.edu.
