From 4ad78423215b8f304567160acffe2b630a29c2a6 Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen Date: Sun, 24 Mar 2002 00:45:54 +0000 Subject: [PATCH] bye bye --- devel/ChangeLog | 24 --- devel/README | 9 -- devel/TODO | 0 devel/build/snarf-macros.text | 0 devel/policy/goals.text | 82 ---------- devel/policy/names.text | 127 ---------------- devel/policy/plans.text | 278 ---------------------------------- devel/policy/principles.text | 0 devel/tasks.text | 124 --------------- 9 files changed, 644 deletions(-) delete mode 100644 devel/ChangeLog delete mode 100644 devel/README delete mode 100644 devel/TODO delete mode 100644 devel/build/snarf-macros.text delete mode 100644 devel/policy/goals.text delete mode 100644 devel/policy/names.text delete mode 100644 devel/policy/plans.text delete mode 100644 devel/policy/principles.text delete mode 100644 devel/tasks.text diff --git a/devel/ChangeLog b/devel/ChangeLog deleted file mode 100644 index ecdb34339..000000000 --- a/devel/ChangeLog +++ /dev/null @@ -1,24 +0,0 @@ -2000-05-30 Mikael Djurfeldt - - * tasks.text: Use outline-mode. Added section for tasks in need - of attention. - -2000-05-29 Mikael Djurfeldt - - * tasks.text: New file. - -2000-05-25 Mikael Djurfeldt - - * README: New file. - - * build/snarf-macros.text: New file. - -2000-05-20 Mikael Djurfeldt - - * policy/goals.text, policy/principles.text, policy/plans.text: - New files. - -2000-03-21 Mikael Djurfeldt - - * policy/names.text: New file. - diff --git a/devel/README b/devel/README deleted file mode 100644 index f6e8553e1..000000000 --- a/devel/README +++ /dev/null @@ -1,9 +0,0 @@ -Directories: - -policy Guile policy documents - -build information related to the build/installation process - -Files: - -tasks.text Guile project task list diff --git a/devel/TODO b/devel/TODO deleted file mode 100644 index e69de29bb..000000000 diff --git a/devel/build/snarf-macros.text b/devel/build/snarf-macros.text deleted file mode 100644 index e69de29bb..000000000 diff --git a/devel/policy/goals.text b/devel/policy/goals.text deleted file mode 100644 index 9ef9aa7f1..000000000 --- a/devel/policy/goals.text +++ /dev/null @@ -1,82 +0,0 @@ -This file states the goals of Guile. - -* Goals of Guile - -Guile is many things to many people. It has multiple ways to approach -it: as a C library that provides an extension language, as a -programming language in its own right, as a interface to the operating -system, as an interactive shell, or as a platform that integrates many -independent subsystems. - -These different roles have a lot in common, but there are also some -opposing forces that need to be balanced. - -Not everything of what is outlined below has been realized yet. The -things that are missing will receive high priority from the -maintainers of Guile. One thing that is not mentioned below because -it goes without saying is documentation. It is of course a goal of -Guile to have high quality documentation. - -More information about the current status of Guile and planned changed -can be found in the file "plans.text". - -** Guile as an extension language library - -Guile's primary aim is to provide a good extension language which is -easy to add to an application written in C on a UNIX machine. This -means that it must export the features of a higher level language in a -way that makes it easy not to break them from C code. - -For example, one important feature of Guile is automatic garbage -collection. The C interface to the garbage collector makes it easy to -use its services for the data structures of the application itself. - -** Guile as a programming language - -It is an aim to support easy programming using Guile. This includes -providing the powerful features of the programming language Scheme, -like garbage collection, dynamic types, hygienic macros and higher -order functions. - -This also includes things that go beyond standard Scheme, like a -module system to manage multiple name spaces, a system for object -oriented programming, support for comfortable multi-threading, and -internationalization features like Unicode support. - -To make it useful, Guile offers good performance. - -** Guile as an interface to the operating system - -Guile supports most of the POSIX system calls. Most of Scsh is -available to Guile users and Guile programs. Beyond POSIX, Guile also -makes available important system libraries like the graphical toolkit -Gtk+. - -** Guile as an interactive shell - -Guile provides a command line interface with readline support. The -interactive features of the programming language allow you to -incrementally alter a running system. A integrated debugger allows -you to analyze such a running system in great detail. - -Guile provides online documentation for most of its features. - -Guile can also be controlled from Emacs. This allows you to update -the definition of a function or some other object in a Guile process -with the touch of a few keys. You have access to the documentation in -a context sensitive way. It also integrates the debugger nicely into -your editing environment. - -** Guile as an integration platform - -With all the features describes above, Guile allows the implementation -of well behaved modules. When most of an application is implemented -as modules with generality and re-usability in mind, Guile will be the -platform where the integration and reusing will take place. - -Thus, Guile makes it easy to factor your application into well -separated modules and then finish it off by combining them with a thin -layer of Scheme code. - -Guile has support for writing modules in C or other compiled -languages. diff --git a/devel/policy/names.text b/devel/policy/names.text deleted file mode 100644 index 1c6bbc2f3..000000000 --- a/devel/policy/names.text +++ /dev/null @@ -1,127 +0,0 @@ -[This is currently a collection of information in an unedited state. - Someone will change this soon.] - -The C names for Scheme primitives *always* obey a fixed name -translation scheme: - -scm_XXX where XXX is translated from the Scheme name, except that - - - becomes _ - ! becomes _x - ? becomes _p - % becomes sys_ - -If there's a C variant of something provided at the Scheme level (like -the current scm_internal_dynamic_wind), it has the prefix scm_c_ -instead of scm_. - -A function named scm_c_FOO serves the same purpose as the function -named scm_FOO, except that its interface is tailored for use from C, -while scm_FOO is tailored for use from Scheme, and is probably -exported as a Scheme primitive. - -For example, scm_FOO might expect Scheme procedures as arguments, -while scm_c_FOO might take C function pointers and a passthrough -value. - - -If there's a C function with global scope which is only intended to be -used internally in libguile, it has the prefix scm_i_. - -String literals with global scope has the prefix scm_s_. (Greg -introduced the prefix s_scm_ but this has to change to scm_s_ since -s_scm_ trespasses the user's namespace.) - -Not correct: Those names have module-local scope and does not trespass -user name space. - -Keywords with global scope has the prefix scm_k_. - -Symbols with global scope has the prefix scm_sym_. - -Variable bindings with global scope has the prefix scm_var_. - -Names, in general, have an internal left-to-right order of increasing -specificity: scm_ is least specific. It is often followed by some -type, like `stack', and, finally, the operation. Example: -scm_stack_length. - -There are exceptions, though: - -* If a name is already established at the Scheme level, this defines - the C name through the translation scheme. - -* According to the rule, we should have `SCM_SMOB_DATA_SET', but we - instead have `SCM_SET_SMOB_DATA'. Generally, `set' should be placed - as far left as possible: - - `port-filename' scm_port_filename - `set-port-filename!' scm_set_port_filename_x - - SCM_SMOB_DATA - SCM_SET_SMOB_DATA - -* Guile has a lot of history with lots of different strange names. - Perhaps a major name overhaul can be done at the same time as we go - through Guile's interfaces to checks soundness and theoretical - properties such as type safety. We *should* be a bit careful with - name changes in order not to break existing application code. - -> Further, I'd love it if macros to create scheme values from C values would -> be named SCM_MAKE_... more consitently. Currently, we have SCM_MAKICHAR -> (OK, this one's been made deprecated), SCM_MAKINUM and others. - -I agree. - -> Also, some macros are used for symbols or keywords. The best solution -> would be to use a similar naming scheme for these also. -> -> It's good to talk about improving guile's API. A clean, consistent and -> beautiful api is, in my belief, important for guile's attractivity, and -> makes learning it easier. - -Yes! - -There are still some open points: - -scm_c_XXX : - Only used for C-level variants of a scm_XXX schene primitive, or - rather to be used for everything that is not a scheme primitive? - -scm_i_XXX : - Only for internal _functions_ or rather for everything that is - internal? For example, scm_sym_ is for symbols that may be used by - users, while scm_i_sym_ is used for guile internally? Otherwise we - can't distinguish between C variables holding symbols that are part of - the official API and internally used C variables holding symbols. - -what about boolean variables/constants? scm_bool_? This would fit nicely - with the current macro names SCM_BOOL_T and SCM_BOOL_F. - -what about number variables/constants? scm_num_? There is at least a - SCM_MAKINUM(0) somewhere... - -scm_s_, scm_k_, scm_sym_, scm_var_: - What about macro variants of these? At least, some symbols and - constants are represented as macros. - -Macros in general: - Should internally used macros be called SCM_I_xxx, thus following the - above scheme? - - How do scheme-level names translate if there are macros that do the - same thing? set-car! --> SCM_SETCAR, thus, the '!' is dropped and the - intermediate '-' is dropped. However, this is not done - consistently: sometimes intermediate '-' are _not_ dropped. - - Currently it seem that: - - - becomes sometimes _ and sometimes nothing - ! becomes nothing - ? becomes P for single-word xxx, _P otherwise - % becomes I don't know what. - - -I would prefer if both worlds (functions/variables and macros) were using -similar schemes as far as possible. (I even dislike the _P/P -distinction, but I know that I am strange :-) diff --git a/devel/policy/plans.text b/devel/policy/plans.text deleted file mode 100644 index 93c4791a0..000000000 --- a/devel/policy/plans.text +++ /dev/null @@ -1,278 +0,0 @@ -This file describes the current status and future plans for Guile development. - -* Status - -To give you an idea how far we are from the things described above, -here is the status of some topics. Guile used to suck, but it doesn't -any more. - -** Documentation - -XXX - Losta stuff, and talk also about updating the web page. - -** Object oriented programming - -Guile's object system is GOOPS. XXX - Some notes about -characteristics and motivations. - -** Multithreading - -At the moment, Guile supports co-operative threading on several -platforms. We do *not* support true kernel threads at present, not -because we don't think that would be way cool, but because it's -really, really hard. We're taking continually taking steps towards -that goal, however. - -Current status is that necessary basic changes to the garbage -collector and the signal handling has been done. (Few are aware of -it, but the SCM_DEFER_INTS/SCM_ALLOW_INTS macros no longer have any -effect!) - -The major remaining work is to protect common resources using mutecis. - -*** Using Guile's COOP threads in a POSIX threaded application - -A recent change has made it possible to mix use of Guile's COOP -threads and POSIX threads in a single application. This is useful, -since some GNOME libraries links with pthreads by default. (Guile -still has to run in a single POSIX thread, and the two thread systems -needs to use independent sets of thread synchronization mechanisms, -however.) - -** Graphical toolkit - -You can access Gtk+ from Guile by using the (separate) guile-gtk -package. The basic machinery of guile-gtk is mostly done but -individual features of Gtk+ are missing. Adding these features is -mostly the job of taking a look whether they are safe to export in -unmodified form and when that is the case, writing a couple of easy -lines of descriptions for the feature. This is mostly busy work. - -XXX - guile-tcltk? - -* Near Future - -What is planned for the near future. - -** Breakpoints and single-stepping in the debugger - -Guile now has a debugger (try `(debug)'). We are planning to -implement breakpoints and single-stepping, and then announce the -debugger in README file and documentation. - -** A new module system - -Integration of Jost Boekemeiers environment implementation. Greg -Badros has promised to try to integrate them. - -On top of that, a new module system will be implemented, but: - 1) We're not settled yet, - 2) we're really trying to settle it, and - 3) we're discovering why the rest of the Scheme scene isn't - settled on this issue either. - -There will be a C API to the new module system. - -** Factorization of Guile into function libraries - -Although Guile is meant to support composing a system from modules -well, it does not make use of this principle itself. The core is -quite monolithic and includes a lot of things that could be separated -out. - -We will be moving such things as networking, posix and regular -expression support to separate modules instead of having them all in -the root namespace. - -** Faster startup - -We will make Guile start up quicker. Guile's current slow startup is -primarily due to 1. inefficient code in a time-critical place in the -current module system, and, 2. that too much code is loaded at -startup. - -** Translators - -XXX - ??? - -*** C-like syntax for Scheme -*** elisp -*** tcl -*** python - -* The Guile wishlist - -** Revision and stabilization of interfaces - -Along with the updating the documentation, we should clean up the -interfaces of Guile. - -It should be well defined which existing Scheme procedures and C -functions and macros are supported as part of the "Guile language" and -which are temporary procedures used in the implementation of Guile or -historical remnants. - -** Full R5RS compliance - -XXX - -** SRFIs - -XXX - -** Reorganization of the numeric code - -Numeric tower - -3. Introduce a subclass of called . - - Such objects contain 7 pointers to C functions handling the argument - combinations (), (INUM), (REAL), (INUM, INUM), (REAL, INUM), - (INUM, REAL) and (REAL, REAL). - - When an is applied, it first uses simple - if-statements to dispatch onto one of these "primitive methods". - If that fails, it behaves as an ordinary generic, i.e., it does - type dispatch. - -4. Turn all standard Guile arithmetic, and comparison operators into - s and break up numbers.c into independent - modules. - -After this, we can easily add new types to the numeric tower. The new -types will be handled a little bit slower than INUMs and REALs, but I -think it will be fast enough. - -Some fundamental changes have already been done that make floating -point calculations more efficient. - -** Low-level support for hygienic macros - -Instead of a well integrated support for hygieneic macros, Guile -provides three redundant ways of defining unhygienic macros: -`procedure->macro', `defmacro' (with `defmacro-public'), and, -`define-macro' (which lacks a "public" version). There is a -syntax-case macro module (hygienic), but that macro system is written -in Scheme and makes loading time extend even further beyond it's -current unacceptable level. - -Guile macros are not compatible with Guile's module system. If you -export a macro, you need to explicitly export all bindings which it -uses. This needs to be fixed. - -It might be benefitial to separate memoization and execution to better -support macro expansion and compile time optimizations. The result of -the macro expansion and memoization pass could be permanentaly stored -on disk to reduce the load time of large programs. This would also -make the integration of a real compiler easier. See next point. - -** Compiler - -Hobbit doesn't support all of the Guile language, produces inefficient -code, and is a very unstructured program which can't be developed -further. - -It iss very important that the compiler and interpreter agree as much -as possible on the language they're implementing. Users should be -able to write code, run it in the interpreter, and then just switch -over to the compiler and have everything work just as it did before. - -To make this possible, the compiler and interpreter should share as -much code as possible. For example, the module system should be -designed to support both. They should use the same parser and the -same macro expander. - -** CORBA - -The way many of the major applications in the GNOME/Gtk+ world are -moving is this: - - Core application code is written in C or some other similarly - low-level langauge. - - However, internally it consists of Bonobo components. - - Bonobo components should in theory be accessible from any language - (someone really ought to write ORBit-guile) and can be recomposed in - ways other how the application originally intended. - -Thus, Gimp and Gnumeric will eventually in effect provide pieces that -can be used from Guile (and other langauges) and recombined; however, -these components will be written to the Bonobo API, not the Guile API, -and will require a CORBA mapping for the target language to work. - -There are advantages and disadvantages to doing things this way as -compared to writing Guile modules; but in either case we must be -prepared to play in this brave new world of components by ensuring -Guile has the proper tools available, because I don't think we are -going to convince the GNOME people that Guile modules provide all they -want from a component model. - -** POSIX threads support - -XXX - -** Faster GC - -We hope so. If someone came up with a running GC that's faster than -what we've got now, that would be extremely interesting. But this -isn't a primary focus. - -** Test suite - -XXX - -** Internationalization/multilingualization - -XXX - -** Integration of Guile into GNU programs - -XXX - -*** Emacs - -XXX - -*** The Gimp - -XXX - -** Soft typing - -XXX - combine with compiler section? - -** Importing changes from SCM - -XXX - -** Guile module repository - -One is to provide a better public face for Guile, and encourage people -to contribute useful extensions. This can be achieved by providing a -repository and managed namespace along the lines of CPAN. - -** More frequent releases - -We will try to make Guile releases more frequently. - -------------------- XXX - add the following to HACKING? - -** The CVS repository - -*** The current CVS version of Guile should always compile - -The current CVS version of Guile should always compile and not contain -major bugs. - -*** Applying patches - -A Guile developer should always fully understand the code in a patch -which he applies, and is responsible for the quality of the applied -patch. - -*** Experimental code - -Experimental code should be kept in the local working copy or -committed onto a branch. The only exception is when some kind of -feedback is needed from other developers or users. diff --git a/devel/policy/principles.text b/devel/policy/principles.text deleted file mode 100644 index e69de29bb..000000000 diff --git a/devel/tasks.text b/devel/tasks.text deleted file mode 100644 index c70807147..000000000 --- a/devel/tasks.text +++ /dev/null @@ -1,124 +0,0 @@ -* People - -neil Neil Jerram -gjb Greg J. Badros -thi thi -peter Peter C. Norton -mvo Marius Vollmer -mdj Mikael Djurfeldt -livshin Michael Livshin -gregh Greg Harvey -niibe NIIBE Yutaka -dirk Dirk Herrmann -rlb Rob Browning -ryanw Ryan Weaver - -* Assigned core tasks - -(? = has shown interest, but has not yet taken on the task) - -** reference manual - -neil - -** docstrings - -gjb - -** Guile FAQ - -thi - -** Guile WWW pages at GNU - -peter - -** Guile project list - -thi - -** Guile Debian package maintainer - -rlb - -** Guile RPM package manager - -ryanw - -** integration of Jost's environments - -gjb - -** generational garbage collection - -gregh -livshin - -** POSIX thread support - -niibe - -*** factorizing thread support out of libguile - -niibe -dirk - -*** Protecting common resources using mutecis from the new interface. - -maciej? - -*** Removing the dynamic roots - -*** Revise the fluid implementation - -Trying to use the thread library's support for thread local data -(get/setspecific). - -*** Implementing the GC thread synchronization (all threads: go to sleep!) - -One suitable synchronization point is probably SCM_TICK. - -Note also that threads which are in I/O or timeout should be regarded -as stopped and that we need synchronization points *after* each I/O or -timeout, so that they really stop afterward if Guile is still in GC. - -*** Implementing the libguileposix threads glue library - -This corresponds to the libguilecoop library implemented during the -thread factorization. - -** GOOPS - -*** integration into libguile - -mdj - -*** developing better representation for GOOPS objects - -livshin - -*** rewrite method cache management in C - -thi - -*** rewrite core macros (define-class et al) in C - -thi - -*** GOOPS C API - -mvo -dirk - -* Core tasks in need of attention - -** GOOPS - -*** Orbit CORBA interface - -Talk to mdj - - -Local Variables: -mode: outline -End: