mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-05-18 18:40:22 +02:00
bye bye
This commit is contained in:
Thien-Thi Nguyen
parent
3c5c187e69
commit
4ad7842321
9 changed files with 0 additions and 644 deletions
|
|
@ -1,24 +0,0 @@
|
|||
2000-05-30 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
||||
|
||||
* tasks.text: Use outline-mode. Added section for tasks in need
|
||||
of attention.
|
||||
|
||||
2000-05-29 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
||||
|
||||
* tasks.text: New file.
|
||||
|
||||
2000-05-25 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
||||
|
||||
* README: New file.
|
||||
|
||||
* build/snarf-macros.text: New file.
|
||||
|
||||
2000-05-20 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
||||
|
||||
* policy/goals.text, policy/principles.text, policy/plans.text:
|
||||
New files.
|
||||
|
||||
2000-03-21 Mikael Djurfeldt <mdj@thalamus.nada.kth.se>
|
||||
|
||||
* policy/names.text: New file.
|
||||
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
Directories:
|
||||
|
||||
policy Guile policy documents
|
||||
|
||||
build information related to the build/installation process
|
||||
|
||||
Files:
|
||||
|
||||
tasks.text Guile project task list
|
||||
|
|
@ -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.
|
||||
|
|
@ -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 :-)
|
||||
|
|
@ -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 <generic> called <arithmetic-generic>.
|
||||
|
||||
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 <arithmetic-generic> 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
|
||||
<arithmetic-generic>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.
|
||||
124
devel/tasks.text
124
devel/tasks.text
|
|
@ -1,124 +0,0 @@
|
|||
* People
|
||||
|
||||
neil Neil Jerram <neil@ossau.uklinux.net>
|
||||
gjb Greg J. Badros <gjb@cs.washington.edu>
|
||||
thi thi <ttn@revel.glug.org>
|
||||
peter Peter C. Norton <spacey@lenin.nu>
|
||||
mvo Marius Vollmer <mvo@zagadka.ping.de>
|
||||
mdj Mikael Djurfeldt <djurfeldt@nada.kth.se>
|
||||
livshin Michael Livshin <mlivshin@bigfoot.com>
|
||||
gregh Greg Harvey <Greg.Harvey@thezone.net>
|
||||
niibe NIIBE Yutaka <gniibe@chroot.org>
|
||||
dirk Dirk Herrmann <dirk@ida.ing.tu-bs.de>
|
||||
rlb Rob Browning <rlb@cs.utexas.edu>
|
||||
ryanw Ryan Weaver <ryanw@infohwy.com>
|
||||
|
||||
* 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:
|
||||
Loading…
Add table
Add a link
Reference in a new issue