https://gambitscheme.org/wiki/api.php?action=feedcontributions&user=Pflanze&feedformat=atomGambit wiki - User contributions [en]2024-03-28T21:46:24ZUser contributionsMediaWiki 1.35.3https://gambitscheme.org/wiki/index.php?title=Summer_Of_Code_2009&diff=2223Summer Of Code 20092009-03-15T05:56:54Z<p>Pflanze: grammatical fixes</p>
<hr />
<div>Please check this page regularly as we will be adding new ideas as they come up.<br />
<br />
Note that this page is editable. If you have suggestions for projects<br />
please add them to the second section ("project suggestions"). The<br />
first section contains the projects that are officially proposed by<br />
the organization. You can make corrections to the text but please<br />
don't make substantial changes.<br />
<br />
The Gambit [[Wish_list | wish list]] may<br />
also be a good source of inspiration for projects. However the wish<br />
list contains projects which require a very good knowledge of the<br />
Gambit system's structure and internal operation, so they are not<br />
advisable for students with little or no experience with Gambit.<br />
<br />
==Official project proposals==<br />
<br />
===Documentation framework===<br />
<br />
Gambit's documentation is mainly in the form of a traditional user<br />
manual. To increase its usefulness it needs to be easier to access<br />
while developing code. Documentation needs to be integrated with the<br />
tools including: from the text editor (pop-up documentation when a<br />
call to a built-in function is typed, with information on parameters),<br />
from the REPL, from the command-line. Moreover the documentation<br />
should be automatically checked for consistency on each release (for<br />
instance by checking that the code examples actually produce the<br />
result indicated).<br />
<br />
Difficulty: easy<br />
<br />
Required skills: Scheme, Gambit, and possibly LaTeX, HTML<br />
<br />
===Gambit packages===<br />
<br />
There is an urgent need for easily reusable packages for miscellaneous<br />
features including data-structures, message digests, encryption,<br />
pattern-matching, regular expressions, etc. Portable Scheme code<br />
already exists for many of these (e.g. SRFI's, Snow packages, Chicken<br />
eggs, etc). The project consists in porting these codes to the Gambit<br />
system and to write new packages when appropriate. We expect the<br />
student to choose the set of packages to port/write based on their<br />
personal interests. Due to the high number of packages that need to<br />
be worked on, this project can accomodate up to 3 students. If more<br />
than one student participates on this project, the mentor will help to<br />
coordinate the work of the students.<br />
<br />
Difficulty: easy to medium<br />
<br />
Required skills: Scheme, Gambit, algorithms<br />
<br />
===SLIME interface===<br />
<br />
SLIME (http://common-lisp.net/project/slime/) is a full-featured Emacs<br />
mode for multithreaded Common Lisp development. A port of it exists<br />
for Scheme48 ("SLIME48"). The project consists in adapting SLIME to<br />
Gambit to allow multithreaded remote debugging from Emacs. The current<br />
gambit.el emacs-lisp package could be used as a starting point.<br />
<br />
Difficulty: medium<br />
<br />
Required skills: emacs-lisp, Scheme, Gambit, multithreading<br />
<br />
===Web framework===<br />
<br />
Thanks to Gambit's high-level networking functions, non-blocking I/O,<br />
and efficient thread system, a simple high-performance web server can<br />
be written in a few minutes. With Gambit's serializable closures and<br />
continuations it is possible to implement cleanly a fancy web<br />
framework with advanced features (client-side computation, task<br />
migration, load balancing, persistent interactions, undoable<br />
transactions). The project consists in constructing the framework to<br />
support these advanced features, and to demonstrate a few of them).<br />
<br />
Difficulty: hard<br />
<br />
Required skills: HTML, HTTP, Scheme, Gambit<br />
<br />
===Native Threading===<br />
<br />
Gambit (like most Scheme systems) implements its own lightweight threading system which is not aware of native, operating system threads. The so-called Gambit Virtual Machine (GVM) can only be bound to one native thread. This makes it difficult to utilize true parallel processing, which will be an important step in adapting to future hardware. This also causes C code to block the entire GVM for the duration of the C code's execution.<br />
<br />
One solution is to use Termite and spawn multiple Gambit processes. Although it is a valid solution, it is unacceptable for any real-time system such as video games. This project aims to extend Gambit in some fashion to utilize system threads. Various solutions and assumptions will be explored: spawn multiple Gambit systems across threads in one process and have a special shared memory buffer? Extend Gambit to enforce pure functional programming?<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Gambit, threading, memory allocation, garbage collection<br />
<br />
===GVM virtual-machine interpreter===<br />
<br />
The Gambit system is based on a virtual machine (the GVM). It is the intermediate representation for the compiler. The size of the generated code is an issue for very large programs (such as the Jedi IDE) and for embedded systems. An interesting approach, to be explored by this project, would be to design a compact bytecode representation for the GVM and implement a bytecode interpreter.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation<br />
<br />
===Module System Infrastructure===<br />
<br />
The Gambit system adhere's to the philosophy of providing basic, robust and efficient infrastructure on top of which users can implement higher-level abstractions. This project consists in designing and implementing a module system infrastructure for Gambit with which more sophisticated module systems can be implemented. In particular it should be possible to use the result of this project to implement the R6RS module system.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Gambit, functional programming, metaprogramming, OO programming<br />
<br />
===Automating FFI Bindings===<br />
<br />
Gambit's foreign-function-interface (FFI) can be tedious to use for interfacing to C libraries with many functions (such as Xlib, OpenGL). There exist some tools to parse header files and extract information relevant to the creation of FFI bindings. For example, SWIG (http://www.swig.org/) is an interface generator that supports several high-level programming languages, including a few Schemes (Chicken, MzScheme, Guile). There is also gcc-xml which is being used in the Ctypes Python library. The goal would be to get one of these tools working with Gambit. The Gambit FFI subsystem will also have to be extended minimally to support features such as "const" types.<br />
<br />
Difficulty: medium<br />
<br />
Required skills: Gambit, C/C++<br />
<br />
==Project suggestions==<br />
<br />
Add to this section any projects you want to suggest to the organizers.<br />
Acceptable projects will be moved to the above section.<br />
<br />
===Flash bytecode / ActionScript back-end===<br />
<br />
This project will explore ways to compile Scheme code into either Bytecode targeted for the Flash Player, or alternatively ActionScript, and write a prototype back-end for the Gambit compiler.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation<br />
<br />
===LLVM back-end===<br />
<br />
A working prototype generating LLVM code (intermediate representation) has been written by two students as part of a term project. Going from this prototype, a back-end covering all of Scheme and Gambit's extensions can be created. This will allow Gambit to take advantage of the LLVM infrastructure, and also allow to compile code without requiring a complete C compilation environment to be installed on the user's machine.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Summer_Of_Code_2009&diff=2222Summer Of Code 20092009-03-14T18:44:44Z<p>Pflanze: Add description</p>
<hr />
<div>Please check this page regularly as we will be adding new ideas as they come up.<br />
<br />
Note that this page is editable. If you have suggestions for projects<br />
please add them to the second section ("project suggestions"). The<br />
first section contains the projects that are officially proposed by<br />
the organization. You can make corrections to the text but please<br />
don't make substantial changes.<br />
<br />
The Gambit [[Wish_list | wish list]] may<br />
also be a good source of inspiration for projects. However the wish<br />
list contains projects which require a very good knowledge of the<br />
Gambit system's structure and internal operation, so they are not<br />
advisable for students with little or no experience with Gambit.<br />
<br />
==Official project proposals==<br />
<br />
===Documentation framework===<br />
<br />
Gambit's documentation is mainly in the form of a traditional user<br />
manual. To increase its usefulness it needs to be easier to access<br />
while developing code. Documentation needs to be integrated with the<br />
tools including: from the text editor (pop-up documentation when a<br />
call to a built-in function is typed, with information on parameters),<br />
from the REPL, from the command-line. Moreover the documentation<br />
should be automatically checked for consistency on each release (for<br />
instance by checking that the code examples actually produce the<br />
result indicated).<br />
<br />
Difficulty: easy<br />
<br />
Required skills: Scheme, Gambit, and possibly LaTeX, HTML<br />
<br />
===Gambit packages===<br />
<br />
There is an urgent need for easily reusable packages for miscellaneous<br />
features including data-structures, message digests, encryption,<br />
pattern-matching, regular expressions, etc. Portable Scheme code<br />
already exists for many of these (e.g. SRFI's, Snow packages, Chicken<br />
eggs, etc). The project consists in porting these codes to the Gambit<br />
system and to write new packages when appropriate. We expect the<br />
student to choose the set of packages to port/write based on their<br />
personal interests. Due to the high number of packages that need to<br />
be worked on, this project can accomodate up to 3 students. If more<br />
than one student participates on this project, the mentor will help to<br />
coordinate the work of the students.<br />
<br />
Difficulty: easy to medium<br />
<br />
Required skills: Scheme, Gambit, algorithms<br />
<br />
===SLIME interface===<br />
<br />
SLIME (http://common-lisp.net/project/slime/) is a full-featured Emacs<br />
mode for multithreaded Common Lisp development. A port of it exists<br />
for Scheme48 ("SLIME48"). The project consists in adapting SLIME to<br />
Gambit to allow multithreaded remote debugging from Emacs. The current<br />
gambit.el emacs-lisp package could be used as a starting point.<br />
<br />
Difficulty: medium<br />
<br />
Required skills: emacs-lisp, Scheme, Gambit, multithreading<br />
<br />
===Web framework===<br />
<br />
Thanks to Gambit's high-level networking functions, non-blocking I/O,<br />
and efficient thread system, a simple high-performance web server can<br />
be written in a few minutes. With Gambit's serializable closures and<br />
continuations it is possible to implement cleanly a fancy web<br />
framework with advanced features (client-side computation, task<br />
migration, load balancing, persistent interactions, undoable<br />
transactions). The project consists in constructing the framework to<br />
support these advanced features, and to demonstrate a few of them).<br />
<br />
Difficulty: hard<br />
<br />
Required skills: HTML, HTTP, Scheme, Gambit<br />
<br />
===Native Threading===<br />
<br />
Gambit (like most Scheme systems) implements its own lightweight threading system which is not aware of native, operating system threads. The so-called Gambit Virtual Machine (GVM) can only be bound to one native thread. This makes it difficult to utilize true parallel processing, which will be an important step in adapting to future hardware. This also causes C code to block the entire GVM for the duration of the C code's execution.<br />
<br />
One solution is to use Termite and spawn multiple Gambit processes. Although it is a valid solution, it is unacceptable for any real-time system such as video games. This project aims to extend Gambit in some fashion to utilize system threads. Various solutions and assumptions will be explored: spawn multiple Gambit systems across threads in one process and have a special shared memory buffer? Extend Gambit to enforce pure functional programming?<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Gambit, threading, memory allocation, garbage collection<br />
<br />
===GVM virtual-machine interpreter===<br />
<br />
The Gambit system is based on a virtual machine (the GVM). It is the intermediate representation for the compiler. The size of the generated code is an issue for very large programs (such as the Jedi IDE) and for embedded systems. An interesting approach, to be explored by this project, would be to design a compact bytecode representation for the GVM and implement a bytecode interpreter.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation<br />
<br />
===Module System Infrastructure===<br />
<br />
The Gambit system adhere's to the philosophy of providing basic, robust and efficient infrastructure on top of which users can implement higher-level abstractions. This project consists in designing and implementing a module system infrastructure for Gambit with which more sophisticated module systems can be implemented. In particular it should be possible to use the result of this project to implement the R6RS module system.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Gambit, functional programming, metaprogramming, OO programming<br />
<br />
===Automating FFI Bindings===<br />
<br />
Gambit's foreign-function-interface (FFI) can be tedious to use for interfacing to C libraries with many functions (such as Xlib, OpenGL). There exist some tools to parse header files and extract information relevant to the creation of FFI bindings. For example, SWIG (http://www.swig.org/) is an interface generator that supports several high-level programming languages, including a few Schemes (Chicken, MzScheme, Guile). There is also gcc-xml which is being used in the Ctypes Python library. The goal would be to get one of these tools working with Gambit. The Gambit FFI subsystem will also have to be extended minimally to support features such as "const" types.<br />
<br />
Difficulty: medium<br />
<br />
Required skills: Gambit, C/C++<br />
<br />
==Project suggestions==<br />
<br />
Add to this section any projects you want to suggest to the organizers.<br />
Acceptable projects will be moved to the above section.<br />
<br />
===Flash bytecode / ActionScript back-end===<br />
<br />
This project will explore ways to compile Scheme code into either Bytecode targeted for the Flash Player, or alternatively ActionScript, and write a prototype back-end for the Gambit compiler.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation<br />
<br />
===LLVM back-end===<br />
<br />
A working prototype generating LLVM code (intermediate representation) has been written by two students as part of a term project. Going from this prototype, a back-end covering all of Scheme and Gambit's extensions can be created. This would Gambit to take advantage of the LLVM infrastructure, and also allow to compile code without requiring a complete C compilation environment to be installed on the user's machine.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Summer_Of_Code_2009&diff=2221Summer Of Code 20092009-03-14T18:35:17Z<p>Pflanze: Add description</p>
<hr />
<div>Please check this page regularly as we will be adding new ideas as they come up.<br />
<br />
Note that this page is editable. If you have suggestions for projects<br />
please add them to the second section ("project suggestions"). The<br />
first section contains the projects that are officially proposed by<br />
the organization. You can make corrections to the text but please<br />
don't make substantial changes.<br />
<br />
The Gambit [[Wish_list | wish list]] may<br />
also be a good source of inspiration for projects. However the wish<br />
list contains projects which require a very good knowledge of the<br />
Gambit system's structure and internal operation, so they are not<br />
advisable for students with little or no experience with Gambit.<br />
<br />
==Official project proposals==<br />
<br />
===Documentation framework===<br />
<br />
Gambit's documentation is mainly in the form of a traditional user<br />
manual. To increase its usefulness it needs to be easier to access<br />
while developing code. Documentation needs to be integrated with the<br />
tools including: from the text editor (pop-up documentation when a<br />
call to a built-in function is typed, with information on parameters),<br />
from the REPL, from the command-line. Moreover the documentation<br />
should be automatically checked for consistency on each release (for<br />
instance by checking that the code examples actually produce the<br />
result indicated).<br />
<br />
Difficulty: easy<br />
<br />
Required skills: Scheme, Gambit, and possibly LaTeX, HTML<br />
<br />
===Gambit packages===<br />
<br />
There is an urgent need for easily reusable packages for miscellaneous<br />
features including data-structures, message digests, encryption,<br />
pattern-matching, regular expressions, etc. Portable Scheme code<br />
already exists for many of these (e.g. SRFI's, Snow packages, Chicken<br />
eggs, etc). The project consists in porting these codes to the Gambit<br />
system and to write new packages when appropriate. We expect the<br />
student to choose the set of packages to port/write based on their<br />
personal interests. Due to the high number of packages that need to<br />
be worked on, this project can accomodate up to 3 students. If more<br />
than one student participates on this project, the mentor will help to<br />
coordinate the work of the students.<br />
<br />
Difficulty: easy to medium<br />
<br />
Required skills: Scheme, Gambit, algorithms<br />
<br />
===SLIME interface===<br />
<br />
SLIME (http://common-lisp.net/project/slime/) is a full-featured Emacs<br />
mode for multithreaded Common Lisp development. A port of it exists<br />
for Scheme48 ("SLIME48"). The project consists in adapting SLIME to<br />
Gambit to allow multithreaded remote debugging from Emacs. The current<br />
gambit.el emacs-lisp package could be used as a starting point.<br />
<br />
Difficulty: medium<br />
<br />
Required skills: emacs-lisp, Scheme, Gambit, multithreading<br />
<br />
===Web framework===<br />
<br />
Thanks to Gambit's high-level networking functions, non-blocking I/O,<br />
and efficient thread system, a simple high-performance web server can<br />
be written in a few minutes. With Gambit's serializable closures and<br />
continuations it is possible to implement cleanly a fancy web<br />
framework with advanced features (client-side computation, task<br />
migration, load balancing, persistent interactions, undoable<br />
transactions). The project consists in constructing the framework to<br />
support these advanced features, and to demonstrate a few of them).<br />
<br />
Difficulty: hard<br />
<br />
Required skills: HTML, HTTP, Scheme, Gambit<br />
<br />
===Native Threading===<br />
<br />
Gambit (like most Scheme systems) implements its own lightweight threading system which is not aware of native, operating system threads. The so-called Gambit Virtual Machine (GVM) can only be bound to one native thread. This makes it difficult to utilize true parallel processing, which will be an important step in adapting to future hardware. This also causes C code to block the entire GVM for the duration of the C code's execution.<br />
<br />
One solution is to use Termite and spawn multiple Gambit processes. Although it is a valid solution, it is unacceptable for any real-time system such as video games. This project aims to extend Gambit in some fashion to utilize system threads. Various solutions and assumptions will be explored: spawn multiple Gambit systems across threads in one process and have a special shared memory buffer? Extend Gambit to enforce pure functional programming?<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Gambit, threading, memory allocation, garbage collection<br />
<br />
===GVM virtual-machine interpreter===<br />
<br />
The Gambit system is based on a virtual machine (the GVM). It is the intermediate representation for the compiler. The size of the generated code is an issue for very large programs (such as the Jedi IDE) and for embedded systems. An interesting approach, to be explored by this project, would be to design a compact bytecode representation for the GVM and implement a bytecode interpreter.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation<br />
<br />
===Module System Infrastructure===<br />
<br />
The Gambit system adhere's to the philosophy of providing basic, robust and efficient infrastructure on top of which users can implement higher-level abstractions. This project consists in designing and implementing a module system infrastructure for Gambit with which more sophisticated module systems can be implemented. In particular it should be possible to use the result of this project to implement the R6RS module system.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Gambit, functional programming, metaprogramming, OO programming<br />
<br />
===Automating FFI Bindings===<br />
<br />
Gambit's foreign-function-interface (FFI) can be tedious to use for interfacing to C libraries with many functions (such as Xlib, OpenGL). There exist some tools to parse header files and extract information relevant to the creation of FFI bindings. For example, SWIG (http://www.swig.org/) is an interface generator that supports several high-level programming languages, including a few Schemes (Chicken, MzScheme, Guile). There is also gcc-xml which is being used in the Ctypes Python library. The goal would be to get one of these tools working with Gambit. The Gambit FFI subsystem will also have to be extended minimally to support features such as "const" types.<br />
<br />
Difficulty: medium<br />
<br />
Required skills: Gambit, C/C++<br />
<br />
==Project suggestions==<br />
<br />
Add to this section any projects you want to suggest to the organizers.<br />
Acceptable projects will be moved to the above section.<br />
<br />
===ActionScript (FLASH) back-end===<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation<br />
<br />
===LLVM back-end===<br />
<br />
A working prototype generating LLVM code (intermediate representation) has been written by two students as part of a term project. Going from this prototype, a back-end covering all of Scheme and Gambit's extensions can be created. This would Gambit to take advantage of the LLVM infrastructure, and also allow to compile code without requiring a complete C compilation environment to be installed on the user's machine.<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Scheme, Gambit, compilation</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=IPhone&diff=2203IPhone2009-02-18T23:21:59Z<p>Pflanze: a start</p>
<hr />
<div>== Gambit on the iPhone ==<br />
<br />
This page is just a tiny start written by someone who is *not* owning an iPhone. Someone with actual experience should change and update this page and paragraph!<br />
<br />
See:<br />
<br />
* http://www.google.com/search?q=gambit+scheme+iphone<br />
* http://weblog.latte.ca/blake/tech/iTouch/gambit.html<br />
<br />
....</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Debugging&diff=425Debugging2009-01-11T14:31:14Z<p>Pflanze: Mention code to use "user-space interned" uninterned symbols</p>
<hr />
<div>(This document is a stub.)<br />
<br />
== Interactive debugging ==<br />
<br />
Gambit features an internal source debugger, see the User Documentation. <br />
<br />
There are currently multiple interactive debuggers in development, please see the mailing list archives.<br />
<br />
== Tracking down mistyped identifiers (i.e. variable and procedure names) ==<br />
Typically you solve this through compiling your code, i.e. (compile-file X), and then load the compiled object file, i.e. (load "file") or (load "file.o1"). The typical warning message is<br />
<br />
*** WARNING -- Variable "namespace-name#identifier-name" used in module "filename.o1" is undefined<br />
<br />
In order to track down the line number of the undefined identifier, compile with the with-gvm option. The addressed row numbers are found on the rows starting with "line " above the rows with occurrences of namespace-name#identifier-name in them, in the gvm file.<br />
<br />
== Tracking down segmentation faults ==<br />
<br />
=== Typical problem sources ===<br />
Invoking anything that is not a procedure in code compiled with (declare (not safe)) does produce sigsegv:s. Thus, any of (#!void) , (#!unbound) , ("Hello") , (123) produce sigsegv:s, if evaluated in code compiled with (declare (not safe)).<br />
<br />
Addressing nonexistant variables in code compiled with (declare (not safe)) may cause this as well, i.e. (string-ref nonexistant-variable 0) or (set! nonexistant-variable 'a-value).<br />
<br />
Also, pay attention that all Gambit-internal functions without typechecks are always invoked with correct parameters. These are prefixed with ##. I.e., the car function with typechecks is (car), and the one without typechecks is (##car). Thus, (car #!void) will not be fatal in code compiled with (declare (safe)), though, (##car #!void) may be fatal in code compiled with (declare (safe)). And, as we already concluded, both these expressions are fatal to execute in code compiled with (declare (not safe)).<br />
<br />
=== Compiling Gambit for debugging purposes ===<br />
Download the latest Gambit sourcecode.<br />
<br />
Unpack it, usually you do that through executing tar xvfz gambc-v4_X_X.tgz in your shell.<br />
<br />
*Run the configure script. It is normally compiled with --enable-single-host flipped on. If you want Gambit to dump internal messages to the file "console" in the current directory, also pass the --enable-debug parameter. To see all options, run ./configure --help.<br />
<br />
*Edit the file makefile using your favourite editor. There are at least two rows that contain the sequence -O1 (i.e. dash O one), in the current version that's the two rows starting with FLAGS_OBJ and FLAGS_DYN. Replace -O1 with -g -O0 . The -g option will make your C compiler include debugging symbols on compilation, and the -O0 will force it not to do any optimizations on the assembly/binary code it generates, thus the mapping of rows of C/C++ code into memory addresses during program execution will be the most precise your C/C++ compiler is capable of generating.<br />
<br />
*Compile Gambit through typing make<br />
<br />
*If you want this Gambit to replace your current installation, run make install<br />
<br />
=== Running compile-file with debugging options flipped on ===<br />
<br />
When running (compile-file ), remember to pass the cc-opts: "-g -O0" .<br />
<br />
Also, there are the options:<br />
<br />
*track-scheme to make the C/C++ compiler use the source Scheme code instead of the source C/C++ code for debugging info. This is an option that you may want to vary during debugging work.<br />
<br />
*keep-c to make compile-file not remove the intermediary C/C++ code file.<br />
<br />
=== Run Gambit in GDB ===<br />
GDB is found on [http://sourceware.org/gdb/ http://sourceware.org/gdb/], and is typically included as an optional package with Linux and BSD distributions.<br />
<br />
From your shell, run<br />
<br />
gdb gsc<br />
<br />
GDB will start. If you want to pass gsc argument, type<br />
<br />
set args=[the arguments]<br />
<br />
for example<br />
<br />
set args=-e "(display \"test\n\")" -<br />
<br />
To start Gambit witihn GDB, type run.<br />
<br />
If your Gambit application crashes, you will get a prompt in GDB indicating so. To get a backtrace of the stack of your program, type bt . The backtrace should also be interesting for anyone who would assist you in finding the reason to the crash.<br />
<br />
To quit, type quit.<br />
<br />
=== Calling the Debugging Cavalry ===<br />
<br />
If you need to, you can cause the runtime system to write a very detailed trace of execution to the file "console" when a project linked with the runtime is run (including gsi/gsc)<br />
<br />
Just do this:<br />
<br />
% cp gsc/gsc non-debugged-gsc<br />
% ./configure CC="gcc -D___DEBUG_HOST_CHANGES" --enable-debug<br />
% make mostlyclean<br />
% make<br />
% cp non-debugged-gsc gsc/gsc # to avoid having a Gambit compiler with tracing<br />
<br />
<br />
=== Other things you may want to do ===<br />
There are ample of debug utilities, for different operating systems, that may be interesting for you to use.<br />
<br />
For instance, strace is an utility that displays all Kernel invocations your application does. Remember to run it with the -Ff options.<br />
<br />
valgrind is an utility that traces memory leaks. (Gambit will not leak memory in itself, but a faulty Foreign Function Interface library could do that.)<br />
<br />
== Memory use ==<br />
<br />
=== Object memory consumption ===<br />
==== In general ====<br />
The internal representation of objects depends on the word size of the processor. Object references are encoded in a single word, either 32 or 64 bits wide, whose lower 2 bits is a type tag giving some partial type information on the object. The upper bits are either a literal value (in the case of fixnums, characters, booleans, and so on) or an encoding of a pointer (in the case of memory allocated objects such as flonums, bignums, pairs, vectors, and other structured objects).<br />
<br />
Memory is allocated in multiples of the word size (4 bytes on a 32 bit processor and 8 bytes on a 64 bit processor) and aligned on the word size. The alignment constraint implies that (at least) the two lower bits of the address are always zero and can thus be overwritten with the type tag to form an object reference. The first word is a header whose lower 8 bits contain the type of the object, and some bits used by the garbage collector. The upper bits encode the length of the object in bytes. Consequently there is a limit on the size of objects and vectors (homogeneous or not) in particular. On a 64 bit processor this is not a problem because lengths up to 64 petabytes are possible (that's a pretty big object!). On a 32 bit processor the length is limited to 16 megabytes, which implies that vectors of more than about 4 million elements cannot be represented.<br />
<br />
==== Integer values ====<br />
Exact integer values are stored internally as fixnums or bignums, depending on their value, and depending on the word size of the processor (currently 32- or 64-bit).<br />
<br />
On 32-bit processors, exact integers in the interval -536870912 .. 536870911 (i.e. -2^(31-2) .. 2^(31-2)-1) are stored as fixnums internally, and exact integers outside of this interval are stored as bignums. For 64 bit processors, the same interval is -2305843009213693952 .. 2305843009213693951 (i.e. -2^(63-2) .. 2^(63-2)-1). <br />
<br />
Bignums are memory allocated objects. They are essentially vectors of unsigned 64 bit integers which store the bits of the 2's complement representation of the integer, in little-endian format. The most significant bit is the sign (1 = negative, 0 = non-negative).<br />
<br />
(Fixnums have a type tag of zero. The upper bits contain the integer value in 2's complement representation. For example the fixnum 15 is encoded with a word whose value is 60 (i.e. 15 * 4).)<br />
<br />
==== String values ====<br />
By default, characters in a string occupy four bytes of memory each (i.e. 32 bits). Consequently all the Unicode characters are storable in strings by default. With this representation, the maximum string size on a 32 bit processor is just over 4 million characters.<br />
<br />
Strings are memory allocated objects stored in memory as uniform vectors of 8, 16 or 32 bit unsigned integers depending on the --enable-char-size=N configure option specified when compiling Gambit from source. That is, --enable-char-size=1 for 8 bit characters, --enable-char-size=2 for 16 bit characters, and --enable-char-size=4 for 32 bit characters.<br />
<br />
In order to save memory, the character size can be decreased. Generally, a size of two bytes is ok for all purposes, except providing a complete set of asian symbols. The Gambit source code, runtime system and libraries use only ASCII characters to allow the system to work properly, including bootstrapping the system, when --enable-char-size=1 is used.<br />
<br />
The reason Gambit works with a fixed character size internally is for performance. If the size had been variable, such as in UTF-8 encoding, determining at what byte position in a string a certain character index is would be a much heavier computational operation. One way to store strings in UTF-8 while still being able to use any Unicode character, would be to maintain the default four-byte character size, store addressed strings UTF-8 encoded in u8vectors, and convert them to strings when you need access to their contents. The conversion to a string can be done like this:<br />
<br />
(read-line (open-input-u8vector (list init: '#u8(40 206 187 32 120 32 120 41) char-encoding: 'UTF-8)) #f) => "(\u03bb x x)"<br />
<br />
=== Reasons to Heap overflow exceptions ===<br />
Heap overflow exceptions are raised if:<br />
<br />
*If a maximum heap size parameter has been specified to Gambit (see the User Documentation), an exception is raised when code is executed that would require a heap bigger than that.<br />
<br />
*If Gambit fails to allocate more memory from the operating system. Generally that happens only when the operating system considers RAM and swap space to be full.<br />
<br />
*If on a 32-bit processor, when attempting to allocate an object bigger than 16MB.<br />
<br />
=== Tracking down excessive memory use ===<br />
<br />
==== Superflouous symbols ====<br />
Symbols are not garbage collected. Thus, if you do (string->symbol X) on gigabytes of string data, then gigabytes of heap space will be permanently allocated for this. If you want to use ample of symbols in your application, use uninterned symbols, generated using make-uninterned-symbol. (See https://webmail.iro.umontreal.ca/pipermail/gambit-list/2008-October/002817.html for an approach to still get uniqe but garbage collectable objects transparently.)<br />
<br />
==== Memory leaks in FFI:s ====<br />
While Gambit garbage collects Scheme objects on its own, objects created by FFI:s may not be garbage collected automatically, and, there may be bugs in FFI:s. If you use an FFI, look at how it should be used carefully, and if you suspect there's a memory leak in it, analyze its sourcecode, and use debug utilities such as valgrind.<br />
<br />
==== Garbage collection threshold ====<br />
Pay attention to the runtime options h (maximum heapsize in kilobytes) and l (livepercent). See the reference manual for more information. Setting livepercent to five means that garbage collection will take place at the time that there are nineteen times more memory allocated for objects that should be garbage collected, than there is memory allocated for objects that should not. The reason the livepercent option is there, is to give a way to control how sparing/generous the garbage collector should be about memory consumption, vs. how heavy/light it should be in CPU load.<br />
<br />
You can always force garbage collection by (##gc).</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Dumping_Grounds&diff=412Dumping Grounds2009-01-07T01:47:46Z<p>Pflanze: Add FFI section and ffi-related-modules</p>
<hr />
<div>Here you will find packages of Gambit code contributed by users. This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them. This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development). It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place. Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs. Hence the name '''Dumping Grounds''' for this page.<br />
<br />
The code need not follow a specific structure. It could simply be a Scheme source file (with a '''.scm''' extension). However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files). For some reason the wiki insists on the package name starting with an upper-case letter. The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.<br />
<br />
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the <nowiki>[[media:Sort-r1.tgz|Sort-r1.tgz]]</nowiki> link, save the page and click on the link to upload your file. If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.<br />
<br />
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]<br />
<br />
==Packages==<br />
===Math===<br />
# '''Pi''': Compute pi to arbitrary precision.<br />
#: Author: Marc Feeley<br />
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])<br />
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.<br />
#: Author: Pierre-Alexandre Fournier<br />
#: Package: (web page) http://carretechnologies.com/scheme/blas/blas.html<br />
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)<br />
#: Author: Pierre-Alexandre Fournier<br />
#: Package: (web page) http://carretechnologies.com/scheme/fftw3/fftw3.html<br />
<br />
===Object Systems===<br />
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different<br />
#: Author: Ken Dickey<br />
#: Package: [[media:oops34.tgz|oops34.tgz]]<br />
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.<br />
#: Author: Ken Dickey<br />
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]<br />
<br />
===Graphics===<br />
# '''Octave''': A simple plotting interface using octave and gnuplot.<br />
#: Author: Pierre-Alexandre Fournier<br />
#: Package: (web page) http://carretechnologies.com/scheme/octave/octave.html<br />
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer<br />
#: Author: James Long<br />
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]<br />
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.<br />
#: Author: David St-Hilaire<br />
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]<br />
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.<br />
#: Author: David St-Hilaire<br />
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]<br />
# '''Cairo''': Bindings for cairo graphics.<br />
#: Author: Marco Benelli<br />
#: Package: [[media:Cairo-r2.tgz|Cairo-r2.tgz]] (old: [[media:Cairo-r1.tgz|Cairo-r1.tgz]])<br />
<br />
===SQL===<br />
# '''MySQL FFI''': FFI for mysql. Unsure about thread-safety, and needs more work<br />
#: Author: Jonathan Arkell<br />
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/<br />
# '''SQLite3''': a minimalistic interface to SQLite3.<br />
#: Author: Marco Benelli<br />
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]<br />
# '''Postgresql''': A socket level client for Postgresql<br />
#: Author: Francesco Bracchi<br />
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]<br />
<br />
===Parsing===<br />
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C<br />
#: Author: Kirill Lisovsky (updated by Dominique Boucher)<br />
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]<br />
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)<br />
#: Author: Francesco Bracchi<br />
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])<br />
<br />
=== Language ===<br />
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler<br />
#: Author: Marc Feeley and Catherine Gaudron<br />
#: Package: [[media:Jss-r1.tgz|Jss-r1.tgz]]<br />
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. <br />
#: Maintainer: Arthur Smyles<br />
#: Package: (web page) http://smyles.com/projects/r6gambit/<br />
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.<br />
#: Author: Marc Feeley and Vincent St-Amour<br />
#: Package: [[media:Picobit-r2.tgz|Picobit-r2.tgz]]<br />
<br />
=== FFI ===<br />
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)<br />
#: Author: Christian Jaeger<br />
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/<br />
<br />
===Utilities===<br />
# '''Sort''': Provides a simple sorting procedure for lists and vectors. The mergesort algorithm is used.<br />
#: Author: Marc Feeley<br />
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]<br />
# '''Bunny Test''': A simple unit testing framework. <br />
#: Author: Jonathan Arkell<br />
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/<br />
# '''GetOpts''': A syntactic form (let-opts) to parse command line options<br />
#: Author: Marco Benelli<br />
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]<br />
<br />
=== Full Applications ===<br />
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.<br />
#: Author: David St-Hilaire<br />
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]<br />
# '''Web Server''': a web server with sessions cookies and server pages.<br />
#: Author: Francesco Bracchi<br />
#: Package: [[media:WebServer-r1.tgz|WebServer-r1.tgz]]<br />
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.<br />
#: Author: Ken Dickey<br />
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]<br />
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games<br />
#: Author: Joel J. Adamson <br />
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html<br />
<br />
[[Category: Code]]</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Paths&diff=377Paths2008-11-28T17:38:17Z<p>Pflanze: Initial rant</p>
<hr />
<div>=== Why do I not like the "~~" and "~~foo" path ideas ===<br />
<br />
by Christian Jaeger, please paint over (with your own graffiti or artwork) as you see fit.<br />
<br />
* they are a layer on top of the underlying OS; and you can't access a file named '~~' in the current directory anymore<br />
<br />
* they are not lispy, in the sense that they are a language by themselves, a sublanguage inside lisp. Just like regex strings are a sublanguage; for the latter a number of lisp/Scheme regex packages provide sexpr based regular expressions.<br />
<br />
* I'm missing a good specification for the sublanguage; it feels ad hoc, which is ok for "local" things but when it comes to files put out into the wild, it's bad if the spec changes and you need to adapt the files.<br />
<br />
* I understand that "~~" means "use a file delivered with core Gambit". This may seem ok now, but it doesn't allow transparent shadowing by the user. This may not seem to be an issue now, but compare with Perl: there would frequently be a module Foo provided with the default installation, but it might be too old for your application, and thus you install a newer Foo from CPAN and because it's coming in the search path before the core Foo you'll be using the newly installed Foo now. Gambit already delivers some utility code like digest.scm, this is a candidate for overriding.<br />
<br />
* Specifying "~~lib/" instead of "~~/lib" to solve the problem where distribution makers are tearing apart the traditional ~~ directory contents, is requiring adaption of the currently written files. If we're going to adapt, it would better be a solution that is meant to stay quite some time. Will this be the case?<br />
<br />
* Specifying the "lib" part at all seems to be redundant: the |include| can only deal with library files anyway, right? Or, if include files are put to "~~include" and library files to "~~lib" consistently, then |load| could as well know by itself that a ~~ path is meant to be a ~~lib path and |include| could know that a ~~ path is meant to be a ~~include path.<br />
<br />
* (~~ is not understood by other Scheme systems, it's only usable for unportable files; this means if digest.scm is portable, it would better not be delivered with Gambit (if this means it requires ~~ in the path to access it).)<br />
<br />
The only thing I wonder is whether the solution at http://scheme.ch/gambit/experimental/paths/paths.scm is too complicated or otherwise has a problem that makes it unsuited.<br />
<br />
That solution *should* be usable for non-Gambit-core files, too. Should there be a hard distinction between core and non-core files? Should all code loading except for Gambit core files be handled by a module system which uses such a solution? But why, if the core procedures like |compile-file| and |load| are good enough for many things, also for non-core code. Is the above linked code really too much of a module/user space feature to be included in the core?<br />
<br />
<br />
Which tools are handling paths how?<br />
<br />
* Perl does it pretty much exactly as shown in http://scheme.ch/gambit/experimental/paths/paths.scm<br />
<br />
* What about other interpreted languages?<br />
<br />
* How does path resolving in gcc for -lfoo etc. exactly work? compare.<br />
<br />
* other tools?</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System/Log&diff=186Module System/Log2008-03-31T11:42:13Z<p>Pflanze: say which list</p>
<hr />
<div>==Day1 (March 12)==<br />
<br />
Christian Jaeger (pflanze) and James Long (jlongster) have met on the #scheme IRC channel on freenode.net, and got some advice (and a provisional gambit wrapper for Riaxpander), and have discussed why hygienic macro systems rename symbols and that when using namespaces in the symbols, this might be enough as "rename" means, thus providing nice integration with preexisting namespace-using Gambit code.<br />
<br />
After that they continued discussion privately and exchanged thoughts on precompiling code and what this has to do with first-class modules ("first-class modules" being a wrapper around namespaces+contents, basically), and more. Decision to start writing wiki pages, accept one student, and announce this to the Gambit mailing list.<br />
<br />
==Days 2-7 (March 13-18)==<br />
<br />
CJ mainly studied GSoC documentation and google group discussions, added license declaration to the project page, discovered #gambit IRC channel (together with JL), carrying out various discussions (with JL, Marc, Guillaume Cartier), checked pkg-config hint by G.Cartier, started reading paper by M.Flatt, created [[Module_System/Virtual_Library]] page, (talk with D. Peschel about [[Namespaces]] wiki page), observed #gsoc channel during the time when GSoC program manager LH explained how selection has happened. Two Mails to the Gambit-ml. "Nothing much", but all in all some learning experiences.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=183Module System2008-03-30T22:01:46Z<p>Pflanze: Lexicons link</p>
<hr />
<div>This is a project to create a module system for Scheme. It does not have a real name yet. For now, it will target the Gambit Scheme system.<br />
<br />
The system is aiming to be complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does ''not'' focus on package distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (runtime inspection and modification, included light-weight build system for the base case to make running code as easy as in any scripting language)<br />
* good code modularity features (parametrization, optional hygienic macros, infrastructure for generics, ..)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with object systems, host languages requiring translation like lazy-by-default variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* attempt portability by moving parts into or building parts on top of the Snow framework (possibly not achieving the same level of integration with the host system without implementing suggested changes of the latter, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
The primary long-term aim is to be very open for extension, by offering open access to the modularization mechanisms and finding the right mechanisms, so as to make it possible to integrate code from different language and modularization philosophies as cleanly as possible, and to make it easier to contribute towards this goal. We are aware that this is a noble aim and that the development will involve many steps of learning and searching for solutions.<br />
<br />
During this process, several systems may be developed which either help daily code development on Gambit or contribute to the understandings and code base for attaining the longer term goals.<br />
<br />
Currently we have the following development steps in mind:<br />
<br />
# during a first phase, the project will continue to develop within the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
# implement a better interface language (like e.g. that of Scheme-48) on the chjmodule code, targetting parametrization<br />
# investigate ideas like those from the CL [http://www.flownet.com/ron/lisp/Lexicons.pdf Lexicons] project for making easier to write macros (without automatic hygiene)<br />
# investigate what automatic hygiene systems exactly need, implement necessary infrastructure<br />
# introduce hygienic macros, maybe by partial adaption of existing code bases (Abdulaziz Ghuloum's, psyntax, Riaxpander, Scheme-48's, Andre v. Tonder's)<br />
<br />
Before, during or after steps 4-5 modules with a lazy-by-default variant of Scheme will be implemented, as an additional play ground for working on the right hooks for code transformations.<br />
<br />
==Leading Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==How to contribute==<br />
<br />
One important part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Partly, the current leading contributors can help with this, partly this has to be worked out (by reading code, asking Marc, and writing documentation).<br />
<br />
Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves reading the right literature and discussing with more experienced people.<br />
<br />
Seeking contact with people in other module development projects is an important duty; we're currently especially thinking of those working with R6RS implementations, and those working on module systems for Common Lisp ([http://www.flownet.com/ron/lisp/Lexicons.pdf Lexicons], PLT-alike module system on CL GSoC proposal by [http://lispnyc.org/soc.clp LispNYC]).<br />
<br />
==Google Summer of Code==<br />
<br />
This project is attempting to participate in the Google Summer of Code campaign under the hospice of [http://lispnyc.org/soc.clp LispNYC] and offers to mentor a student. There are several possibilities for contribution, depending on the background of the student. One is to tackle one or more of the above development steps. Another one could be to work with the PLT-for-CL project and port it to our infrastructure.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long is reading literature, and experimenting with several existing Scheme module systems<br />
* Christian Jaeger finishes up and announces the long-promised new chjmodule release<br />
* seeking contact with the other module projects, student selection if possible<br />
* seeking more input, continuing to work on chjmodule and gambit-modules to proceed with the above development step list<br />
<br />
==Virtual Library==<br />
<br />
We are keeping a growing [[Module_System/Virtual_Library|list of literature]] which we think is relevant for our work. It contains items we've read or intend to read, so it will be growing; we will not put anything there which we don't think we will manage to read, so by looking at that list you can see whether we are missing something you think we should know about. We hope that you will notify us in this case.<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.<br />
<br />
==License==<br />
<br />
The project intends, for the time being, to license all code under the same licenses as Gambit, namely dual LGPL version 2.1 or Apache version 2.0 license (freely choosable). Requirements for making the code portable may lead us to change the license in due course.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System/Virtual_Library&diff=182Module System/Virtual Library2008-03-30T21:59:32Z<p>Pflanze: add Lexicons document</p>
<hr />
<div>List of papers, books, articles, online discussions or other information that may be relevant for our work. (This doesn't mean those definitely will have an impact on our work; it's not a "references" list in the sense as used by papers written after finishing some work.)<br />
<br />
<br />
* [http://www.cs.utah.edu/plt/publications/macromod.pdf Composable and Compilable Macros] by Matthew Flatt <br />
* [http://okmij.org/ftp/Computation/staging/meta-scheme.scm MetaScheme, or untyped MetaOCaml] by Oleg Kiselyov<br />
* [http://citeseer.ist.psu.edu/109510.html The Scheme of Things: Implementing Lexically Scoped Macros] by Jonathan Rees<br />
* [http://citeseer.ist.psu.edu/bawden88syntactic.html Syntactic Closures] by Alan Bawden, Jonathan Rees<br />
* [http://www.flownet.com/ron/lisp/Lexicons.pdf Lexicons] by Ron Garret (for Common Lisp)</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=181Module System2008-03-30T21:57:00Z<p>Pflanze: major overhaul</p>
<hr />
<div>This is a project to create a module system for Scheme. It does not have a real name yet. For now, it will target the Gambit Scheme system.<br />
<br />
The system is aiming to be complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does ''not'' focus on package distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (runtime inspection and modification, included light-weight build system for the base case to make running code as easy as in any scripting language)<br />
* good code modularity features (parametrization, optional hygienic macros, infrastructure for generics, ..)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with object systems, host languages requiring translation like lazy-by-default variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* attempt portability by moving parts into or building parts on top of the Snow framework (possibly not achieving the same level of integration with the host system without implementing suggested changes of the latter, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
The primary long-term aim is to be very open for extension, by offering open access to the modularization mechanisms and finding the right mechanisms, so as to make it possible to integrate code from different language and modularization philosophies as cleanly as possible, and to make it easier to contribute towards this goal. We are aware that this is a noble aim and that the development will involve many steps of learning and searching for solutions.<br />
<br />
During this process, several systems may be developed which either help daily code development on Gambit or contribute to the understandings and code base for attaining the longer term goals.<br />
<br />
Currently we have the following development steps in mind:<br />
<br />
# during a first phase, the project will continue to develop within the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
# implement a better interface language (like e.g. that of Scheme-48) on the chjmodule code, targetting parametrization<br />
# investigate ideas like those from the CL Lexicons project for making easier to write macros (without automatic hygiene)<br />
# investigate what automatic hygiene systems exactly need, implement necessary infrastructure<br />
# introduce hygienic macros, maybe by partial adaption of existing code bases (Abdulaziz Ghuloum's, psyntax, Riaxpander, Scheme-48's, Andre v. Tonder's)<br />
<br />
Before, during or after steps 4-5 modules with a lazy-by-default variant of Scheme will be implemented, as an additional play ground for working on the right hooks for code transformations.<br />
<br />
==Leading Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==How to contribute==<br />
<br />
One important part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Partly, the current leading contributors can help with this, partly this has to be worked out (by reading code, asking Marc, and writing documentation).<br />
<br />
Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves reading the right literature and discussing with more experienced people.<br />
<br />
Seeking contact with people in other module development projects is an important duty; we're currently especially thinking of those working with R6RS implementations, and those working on module systems for Common Lisp (Lexicons, PLT-alike module system on CL GSoC proposal by [http://lispnyc.org/soc.clp LispNYC]).<br />
<br />
==Google Summer of Code==<br />
<br />
This project is attempting to participate in the Google Summer of Code campaign under the hospice of [http://lispnyc.org/soc.clp LispNYC] and offers to mentor a student. There are several possibilities for contribution, depending on the background of the student. One is to tackle one or more of the above development steps. Another one could be to work with the PLT-for-CL project and port it to our infrastructure.<br />
<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long is reading literature, and experimenting with several existing Scheme module systems<br />
* Christian Jaeger finishes up and announces the long-promised new chjmodule release<br />
* seeking contact with the other module projects, student selection if possible<br />
* seeking more input, continuing to work on chjmodule and gambit-modules to proceed with the above development step list<br />
<br />
==Virtual Library==<br />
<br />
We are keeping a growing [[Module_System/Virtual_Library|list of literature]] which we think is relevant for our work. It contains items we've read or intend to read, so it will be growing; we will not put anything there which we don't think we will manage to read, so by looking at that list you can see whether we are missing something you think we should know about. We hope that you will notify us in this case.<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.<br />
<br />
==License==<br />
<br />
The project intends, for the time being, to license all code under the same licenses as Gambit, namely dual LGPL version 2.1 or Apache version 2.0 license (freely choosable). Requirements for making the code portable may lead us to change the license in due course.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=134Module System2008-03-18T23:06:12Z<p>Pflanze: Make it clear that the License may be discussed</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Summer of Code==<br />
<br />
(This project is attempting to participate in the [[GSoC_ideas_list|Google Summer of Code]] campaign and intends to accept one student as additional core contributor.) Gambit has not been accepted by the GSoC, so this part is moot now (and this section will thus be removed soon); the project will proceed nonetheless.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long goes on reading literature for the next ~two weeks<br />
* Christian Jaeger finishes up and announces the long-promised chjmodule release, and contacts James Long.<br />
* seeking input in the Gambit community, student selection if possible<br />
* seeking input in the wider area, continuing to work on chjmodule and gambit-modules to work out thoughts<br />
* find out the necessary essentials<br />
* fork off a new code base and start implementing new infrastructure<br />
* start coding features<br />
<br />
==Virtual Library==<br />
<br />
We are keeping a growing [[Module_System/Virtual_Library|list of literature]] which we think is relevant for our work. It contains items we've read or intend to read, so it will be growing; we will not put anything there which we don't think we will manage to read, so by looking at that list you can see whether we are missing something you think we should know about. We hope that you will notify us in this case.<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.<br />
<br />
==License==<br />
<br />
The project intends, for the time being, to license all code under the same licenses as Gambit, namely dual LGPL version 2.1 or Apache version 2.0 license (freely choosable). Requirements for making the code portable may lead us to change the license in due course.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=133Module System2008-03-18T23:02:19Z<p>Pflanze: growing list</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Summer of Code==<br />
<br />
(This project is attempting to participate in the [[GSoC_ideas_list|Google Summer of Code]] campaign and intends to accept one student as additional core contributor.) Gambit has not been accepted by the GSoC, so this part is moot now (and this section will thus be removed soon); the project will proceed nonetheless.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long goes on reading literature for the next ~two weeks<br />
* Christian Jaeger finishes up and announces the long-promised chjmodule release, and contacts James Long.<br />
* seeking input in the Gambit community, student selection if possible<br />
* seeking input in the wider area, continuing to work on chjmodule and gambit-modules to work out thoughts<br />
* find out the necessary essentials<br />
* fork off a new code base and start implementing new infrastructure<br />
* start coding features<br />
<br />
==Virtual Library==<br />
<br />
We are keeping a growing [[Module_System/Virtual_Library|list of literature]] which we think is relevant for our work. It contains items we've read or intend to read, so it will be growing; we will not put anything there which we don't think we will manage to read, so by looking at that list you can see whether we are missing something you think we should know about. We hope that you will notify us in this case.<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.<br />
<br />
==License==<br />
<br />
The project will license all code under the same licenses as Gambit, namely dual LGPL version 2.1 or Apache version 2.0 license (freely choosable).</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=132Module System2008-03-18T23:01:14Z<p>Pflanze: Add Virtual_Library reference</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Summer of Code==<br />
<br />
(This project is attempting to participate in the [[GSoC_ideas_list|Google Summer of Code]] campaign and intends to accept one student as additional core contributor.) Gambit has not been accepted by the GSoC, so this part is moot now (and this section will thus be removed soon); the project will proceed nonetheless.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long goes on reading literature for the next ~two weeks<br />
* Christian Jaeger finishes up and announces the long-promised chjmodule release, and contacts James Long.<br />
* seeking input in the Gambit community, student selection if possible<br />
* seeking input in the wider area, continuing to work on chjmodule and gambit-modules to work out thoughts<br />
* find out the necessary essentials<br />
* fork off a new code base and start implementing new infrastructure<br />
* start coding features<br />
<br />
==Virtual Library==<br />
<br />
We are keeping a [[Module_System/Virtual_Library|list of literature]] which we think is relevant for our work. It contains items we've read or intend to read, so it will be growing; we will not put anything there which we don't think we will manage to read, so by looking at that list you can see whether we are missing something you think we should know about. We hope that you will notify us in this case.<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.<br />
<br />
==License==<br />
<br />
The project will license all code under the same licenses as Gambit, namely dual LGPL version 2.1 or Apache version 2.0 license (freely choosable).</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=131Module System2008-03-18T22:52:44Z<p>Pflanze: Section about GSoC "commented out" (for future removal)</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Summer of Code==<br />
<br />
(This project is attempting to participate in the [[GSoC_ideas_list|Google Summer of Code]] campaign and intends to accept one student as additional core contributor.) Gambit has not been accepted by the GSoC, so this part is moot now (and this section will thus be removed soon); the project will proceed nonetheless.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long goes on reading literature for the next ~two weeks<br />
* Christian Jaeger finishes up and announces the long-promised chjmodule release, and contacts James Long.<br />
* seeking input in the Gambit community, student selection if possible<br />
* seeking input in the wider area, continuing to work on chjmodule and gambit-modules to work out thoughts<br />
* find out the necessary essentials<br />
* fork off a new code base and start implementing new infrastructure<br />
* start coding features<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.<br />
<br />
==License==<br />
<br />
The project will license all code under the same licenses as Gambit, namely dual LGPL version 2.1 or Apache version 2.0 license (freely choosable).</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System/Log&diff=130Module System/Log2008-03-18T22:46:09Z<p>Pflanze: CJ Days 2-7 Additions</p>
<hr />
<div>==Day1 (March 12)==<br />
<br />
Christian Jaeger (pflanze) and James Long (jlongster) have met on the #scheme IRC channel on freenode.net, and got some advice (and a provisional gambit wrapper for Riaxpander), and have discussed why hygienic macro systems rename symbols and that when using namespaces in the symbols, this might be enough as "rename" means, thus providing nice integration with preexisting namespace-using Gambit code.<br />
<br />
After that they continued discussion privately and exchanged thoughts on precompiling code and what this has to do with first-class modules ("first-class modules" being a wrapper around namespaces+contents, basically), and more. Decision to start writing wiki pages, accept one student, and announce this to the list.<br />
<br />
==Days 2-7 (March 13-18)==<br />
<br />
CJ mainly studied GSoC documentation and google group discussions, added license declaration to the project page, discovered #gambit IRC channel (together with JL), carrying out various discussions (with JL, Marc, Guillaume Cartier), checked pkg-config hint by G.Cartier, started reading paper by M.Flatt, created [[Module_System/Virtual_Library]] page, (talk with D. Peschel about [[Namespaces]] wiki page), observed #gsoc channel during the time when GSoC program manager LH explained how selection has happened. Two Mails to the Gambit-ml. "Nothing much", but all in all some learning experiences.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System/Log&diff=129Module System/Log2008-03-18T22:25:14Z<p>Pflanze: CJ Days 2-7</p>
<hr />
<div>==Day1 (March 12)==<br />
<br />
Christian Jaeger (pflanze) and James Long (jlongster) have met on the #scheme IRC channel on freenode.net, and got some advice (and a provisional gambit wrapper for Riaxpander), and have discussed why hygienic macro systems rename symbols and that when using namespaces in the symbols, this might be enough as "rename" means, thus providing nice integration with preexisting namespace-using Gambit code.<br />
<br />
After that they continued discussion privately and exchanged thoughts on precompiling code and what this has to do with first-class modules ("first-class modules" being a wrapper around namespaces+contents, basically), and more. Decision to start writing wiki pages, accept one student, and announce this to the list.<br />
<br />
==Days 2-7 (March 13-18)==<br />
<br />
CJ mainly studied GSoC documentation and google group discussions, discovered #gambit IRC channel (together with JL), carrying out various discussions, started reading paper by M.Flatt, created [[Module_System/Virtual_Library]] page, observed #gsoc channel during the time when GSoC program manager LH explained how selection has happened to people. Two Mails to the Gambit-ml. "Nothing much", but all in all some learning experiences.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System/Virtual_Library&diff=117Module System/Virtual Library2008-03-17T09:51:31Z<p>Pflanze: Oleg's surname</p>
<hr />
<div>List of papers, books, articles, online discussions or other information that may be relevant for our work. (This doesn't mean those definitely will have an impact on our work; it's not a "references" list in the sense as used by papers written after finishing some work.)<br />
<br />
<br />
* [http://www.cs.utah.edu/plt/publications/macromod.pdf Composable and Compilable Macros] by Matthew Flatt <br />
* [http://okmij.org/ftp/Computation/staging/meta-scheme.scm MetaScheme, or untyped MetaOCaml] by Oleg Kiselyov</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System/Virtual_Library&diff=116Module System/Virtual Library2008-03-17T09:35:23Z<p>Pflanze: First two entries</p>
<hr />
<div>List of papers, books, articles, online discussions or other information that may be relevant for our work. (This doesn't mean those definitely will have an impact on our work; it's not a "references" list in the sense as used by papers written after finishing some work.)<br />
<br />
<br />
* [http://www.cs.utah.edu/plt/publications/macromod.pdf Composable and Compilable Macros] by Matthew Flatt <br />
* [http://okmij.org/ftp/Computation/staging/meta-scheme.scm MetaScheme, or untyped MetaOCaml] by Oleg</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=109Module System2008-03-15T20:17:34Z<p>Pflanze: fix "summer" (huh, another of those German slip-through's)</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Summer of Code==<br />
<br />
This project is attempting to participate in the [[GSoC_ideas_list|Google Summer of Code]] campaign and intends to accept one student as additional core contributor.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long goes on reading literature for the next ~two weeks<br />
* Christian Jaeger finishes up and announces the long-promised chjmodule release, and contacts James Long.<br />
* seeking input in the Gambit community, student selection if possible<br />
* seeking input in the wider area, continuing to work on chjmodule and gambit-modules to work out thoughts<br />
* find out the necessary essentials<br />
* fork off a new code base and start implementing new infrastructure<br />
* start coding features<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.<br />
<br />
==License==<br />
<br />
The project will license all code under the same licenses as Gambit, namely dual LGPL version 2.1 or Apache version 2.0 license (freely choosable).</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=104Module System2008-03-13T13:56:02Z<p>Pflanze: Added License statement</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Sommer of Code==<br />
<br />
This project is attempting to participate in the [[GSoC_ideas_list|Google Sommer of Code]] campaign and intends to accept one student as additional core contributor.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long goes on reading literature for the next ~two weeks<br />
* Christian Jaeger finishes up and announces the long-promised chjmodule release, and contacts James Long.<br />
* seeking input in the Gambit community, student selection if possible<br />
* seeking input in the wider area, continuing to work on chjmodule and gambit-modules to work out thoughts<br />
* find out the necessary essentials<br />
* fork off a new code base and start implementing new infrastructure<br />
* start coding features<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.<br />
<br />
==License==<br />
<br />
The project will license all code under the same licenses as Gambit, namely dual LGPL version 2.1 or Apache version 2.0 license (freely choosable).</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=103Module System2008-03-13T01:18:01Z<p>Pflanze: Fix Snow! reference</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [http://snow.iro.umontreal.ca/ Snow] package system: unlike Snow, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Sommer of Code==<br />
<br />
This project is attempting to participate in the [[GSoC_ideas_list|Google Sommer of Code]] campaign and intends to accept one student as additional core contributor.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long goes on reading literature for the next ~two weeks<br />
* Christian Jaeger finishes up and announces the long-promised chjmodule release, and contacts James Long.<br />
* seeking input in the Gambit community, student selection if possible<br />
* seeking input in the wider area, continuing to work on chjmodule and gambit-modules to work out thoughts<br />
* find out the necessary essentials<br />
* fork off a new code base and start implementing new infrastructure<br />
* start coding features<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=102Module System2008-03-13T01:15:59Z<p>Pflanze: Added Timeline and Log reference</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [[Snow!]] package system: unlike Snow!, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Sommer of Code==<br />
<br />
This project is attempting to participate in the [[GSoC_ideas_list|Google Sommer of Code]] campaign and intends to accept one student as additional core contributor.<br />
<br />
==Timeline==<br />
<br />
Rough points of the planned timeline:<br />
<br />
* James Long goes on reading literature for the next ~two weeks<br />
* Christian Jaeger finishes up and announces the long-promised chjmodule release, and contacts James Long.<br />
* seeking input in the Gambit community, student selection if possible<br />
* seeking input in the wider area, continuing to work on chjmodule and gambit-modules to work out thoughts<br />
* find out the necessary essentials<br />
* fork off a new code base and start implementing new infrastructure<br />
* start coding features<br />
<br />
==Log==<br />
<br />
There is a [[Module_System/Log|logfile]] mentioning the events in the project.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System/Log&diff=100Module System/Log2008-03-13T01:09:45Z<p>Pflanze: First day</p>
<hr />
<div>==Day1 (March 12)==<br />
<br />
Christian Jaeger (pflanze) and James Long (jlongster) have met on the #scheme IRC channel on freenode.net, and got some advice (and a provisional gambit wrapper for Riaxpander), and have discussed why hygienic macro systems rename symbols and that when using namespaces in the symbols, this might be enough as "rename" means, thus providing nice integration with preexisting namespace-using Gambit code.<br />
<br />
After that they continued discussion privately and exchanged thoughts on precompiling code and what this has to do with first-class modules ("first-class modules" being a wrapper around namespaces+contents, basically), and more. Decision to start writing wiki pages, accept one student, and announce this to the list.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=GSoC_ideas_list&diff=99GSoC ideas list2008-03-13T00:57:02Z<p>Pflanze: /* Module System */</p>
<hr />
<div>Here is the ideas list for the 2008 GSoC program. Please check this<br />
page regularly as we will be adding new ideas as they come up.<br />
<br />
Note that this page is editable. If you have suggestions for projects<br />
please add them to the second section ("project suggestions"). The<br />
first section contains the projects that are officially proposed by<br />
the organization. You can make corrections to the text but please<br />
don't make substantial changes.<br />
<br />
The Gambit [[Wish_list | wish list]] may<br />
also be a good source of inspiration for projects. However the wish<br />
list contains projects which require a very good knowledge of the<br />
Gambit system's structure and internal operation, so they are not<br />
advisable for students with little or no experience with Gambit.<br />
<br />
==Official project proposals==<br />
<br />
===Documentation framework===<br />
<br />
Gambit's documentation is mainly in the form of a traditional user<br />
manual. To increase its usefulness it needs to be easier to access<br />
while developing code. Documentation needs to be integrated with the<br />
tools including: from the text editor (pop-up documentation when a<br />
call to a built-in function is typed, with information on parameters),<br />
from the REPL, from the command-line. Moreover the documentation<br />
should be automatically checked for consistency on each release (for<br />
instance by checking that the code examples actually produce the<br />
result indicated).<br />
<br />
Difficulty: easy<br />
<br />
Required skills: Scheme, Gambit, and possibly LaTeX, HTML<br />
<br />
===Gambit packages===<br />
<br />
There is an urgent need for easily reusable packages for miscellaneous<br />
features including data-structures, message digests, encryption,<br />
pattern-matching, regular expressions, etc. Portable Scheme code<br />
already exists for many of these (e.g. SRFI's, Snow packages, Chicken<br />
eggs, etc). The project consists in porting these codes to the Gambit<br />
system and to write new packages when appropriate. We expect the<br />
student to choose the set of packages to port/write based on their<br />
personal interests. Due to the high number of packages that need to<br />
be worked on, this project can accomodate up to 3 students. If more<br />
than one student participates on this project, the mentor will help to<br />
coordinate the work of the students.<br />
<br />
Difficulty: easy to medium<br />
<br />
Required skills: Scheme, Gambit, algorithms<br />
<br />
===Termite package===<br />
<br />
Termite is a thin layer on top of Gambit which provides Erlang-like<br />
features for concurrent and distributed computing. The current code's<br />
integration with Gambit could be improved. The project consists in<br />
cleaning up the code and turning it into a package that can easily be<br />
loaded into Gambit to extend the runtime system.<br />
<br />
Difficulty: medium to hard<br />
<br />
Required skills: Scheme, Gambit, multithreading, continuations, networking<br />
<br />
===SLIME interface===<br />
<br />
SLIME (http://common-lisp.net/project/slime/) is a full-featured Emacs<br />
mode for multithreaded Common Lisp development. A port of it exists<br />
for Scheme48 ("SLIME48"). The project consists in adapting SLIME to<br />
Gambit to allow multithreaded remote debugging from Emacs. The current<br />
gambit.el emacs-lisp package could be used as a starting point.<br />
<br />
Difficulty: medium<br />
<br />
Required skills: emacs-lisp, Scheme, Gambit, multithreading<br />
<br />
===Web framework===<br />
<br />
Thanks to Gambit's high-level networking functions, non-blocking I/O,<br />
and efficient thread system, a simple high-performance web server can<br />
be written in a few minutes. With Gambit's serializable closures and<br />
continuations it is possible to implement cleanly a fancy web<br />
framework with advanced features (client-side computation, task<br />
migration, load balancing, persistent interactions, undoable<br />
transactions). The project consists in constructing the framework to<br />
support these advanced features, and to demonstrate a few of them).<br />
<br />
Difficulty: hard<br />
<br />
Required skills: HTML, HTTP, Scheme, Gambit<br />
<br />
==Project suggestions==<br />
<br />
Add to this section any projects you want to suggest to the organizers.<br />
Acceptable projects will be moved to the above section.<br />
<br />
===Native Threading===<br />
<br />
Gambit (like most Scheme systems) implements its own lightweight threading system which is not aware of native, operating system threads. The so-called Gambit Virtual Machine (GVM) can only be bound to one native thread. This makes it difficult to utilize true parallel processing, which will be an important step in adapting to future hardware. This also causes C code to block the entire GVM for the duration of the C code's execution.<br />
<br />
One solution is to use Termite and spawn multiple Gambit processes. Although it is a valid solution, it is unacceptable for any real-time system such as video games. This project aims to extend Gambit in some fashion to utilize system threads. Various solutions and assumptions will be explored: spawn multiple Gambit systems across threads in one process and have a special shared memory buffer? Extend Gambit to enforce pure functional programming?<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Gambit, threading, memory allocation, garbage collection<br />
<br />
<br />
===Module System===<br />
<br />
Gambit offers a simple namespace handling system for code compartimentalization, and the Snow! code compartimentalization and distribution system improves on this. That shouldn't be the end of modular programming in the Gambit world, though, and a project exploring that space is underway here: [[Module_System]]. The project could use one student as complemention of the team. Depending on the skills of the student, he/she could tackle different parts (help compiling all requirements onto a minimal set of features (maybe formal description of the problem spaces, finding missing pieces when coming from an OO background, ..), or implementing parts of the system).<br />
<br />
Difficulty: generally rather hard <br />
<br />
Required skills: (Gambit), functional programming, metaprogramming, (OO programming)</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=GSoC_ideas_list&diff=98GSoC ideas list2008-03-13T00:55:46Z<p>Pflanze: Added Module System section</p>
<hr />
<div>Here is the ideas list for the 2008 GSoC program. Please check this<br />
page regularly as we will be adding new ideas as they come up.<br />
<br />
Note that this page is editable. If you have suggestions for projects<br />
please add them to the second section ("project suggestions"). The<br />
first section contains the projects that are officially proposed by<br />
the organization. You can make corrections to the text but please<br />
don't make substantial changes.<br />
<br />
The Gambit [[Wish_list | wish list]] may<br />
also be a good source of inspiration for projects. However the wish<br />
list contains projects which require a very good knowledge of the<br />
Gambit system's structure and internal operation, so they are not<br />
advisable for students with little or no experience with Gambit.<br />
<br />
==Official project proposals==<br />
<br />
===Documentation framework===<br />
<br />
Gambit's documentation is mainly in the form of a traditional user<br />
manual. To increase its usefulness it needs to be easier to access<br />
while developing code. Documentation needs to be integrated with the<br />
tools including: from the text editor (pop-up documentation when a<br />
call to a built-in function is typed, with information on parameters),<br />
from the REPL, from the command-line. Moreover the documentation<br />
should be automatically checked for consistency on each release (for<br />
instance by checking that the code examples actually produce the<br />
result indicated).<br />
<br />
Difficulty: easy<br />
<br />
Required skills: Scheme, Gambit, and possibly LaTeX, HTML<br />
<br />
===Gambit packages===<br />
<br />
There is an urgent need for easily reusable packages for miscellaneous<br />
features including data-structures, message digests, encryption,<br />
pattern-matching, regular expressions, etc. Portable Scheme code<br />
already exists for many of these (e.g. SRFI's, Snow packages, Chicken<br />
eggs, etc). The project consists in porting these codes to the Gambit<br />
system and to write new packages when appropriate. We expect the<br />
student to choose the set of packages to port/write based on their<br />
personal interests. Due to the high number of packages that need to<br />
be worked on, this project can accomodate up to 3 students. If more<br />
than one student participates on this project, the mentor will help to<br />
coordinate the work of the students.<br />
<br />
Difficulty: easy to medium<br />
<br />
Required skills: Scheme, Gambit, algorithms<br />
<br />
===Termite package===<br />
<br />
Termite is a thin layer on top of Gambit which provides Erlang-like<br />
features for concurrent and distributed computing. The current code's<br />
integration with Gambit could be improved. The project consists in<br />
cleaning up the code and turning it into a package that can easily be<br />
loaded into Gambit to extend the runtime system.<br />
<br />
Difficulty: medium to hard<br />
<br />
Required skills: Scheme, Gambit, multithreading, continuations, networking<br />
<br />
===SLIME interface===<br />
<br />
SLIME (http://common-lisp.net/project/slime/) is a full-featured Emacs<br />
mode for multithreaded Common Lisp development. A port of it exists<br />
for Scheme48 ("SLIME48"). The project consists in adapting SLIME to<br />
Gambit to allow multithreaded remote debugging from Emacs. The current<br />
gambit.el emacs-lisp package could be used as a starting point.<br />
<br />
Difficulty: medium<br />
<br />
Required skills: emacs-lisp, Scheme, Gambit, multithreading<br />
<br />
===Web framework===<br />
<br />
Thanks to Gambit's high-level networking functions, non-blocking I/O,<br />
and efficient thread system, a simple high-performance web server can<br />
be written in a few minutes. With Gambit's serializable closures and<br />
continuations it is possible to implement cleanly a fancy web<br />
framework with advanced features (client-side computation, task<br />
migration, load balancing, persistent interactions, undoable<br />
transactions). The project consists in constructing the framework to<br />
support these advanced features, and to demonstrate a few of them).<br />
<br />
Difficulty: hard<br />
<br />
Required skills: HTML, HTTP, Scheme, Gambit<br />
<br />
==Project suggestions==<br />
<br />
Add to this section any projects you want to suggest to the organizers.<br />
Acceptable projects will be moved to the above section.<br />
<br />
===Native Threading===<br />
<br />
Gambit (like most Scheme systems) implements its own lightweight threading system which is not aware of native, operating system threads. The so-called Gambit Virtual Machine (GVM) can only be bound to one native thread. This makes it difficult to utilize true parallel processing, which will be an important step in adapting to future hardware. This also causes C code to block the entire GVM for the duration of the C code's execution.<br />
<br />
One solution is to use Termite and spawn multiple Gambit processes. Although it is a valid solution, it is unacceptable for any real-time system such as video games. This project aims to extend Gambit in some fashion to utilize system threads. Various solutions and assumptions will be explored: spawn multiple Gambit systems across threads in one process and have a special shared memory buffer? Extend Gambit to enforce pure functional programming?<br />
<br />
Difficulty: hard<br />
<br />
Required skills: Gambit, threading, memory allocation, garbage collection<br />
<br />
<br />
===Module System===<br />
<br />
Gambit offers a simple namespace handling system for code compartimentalization, and the Snow! code compartimentalization and distribution system improves on this. That shouldn't be the end of modular programming in the Scheme world, though, and a project exploring that space is underway here: [[Module_System]]. The project could use one student as complemention of the team. Depending on the skills of the student, he/she could tackle different parts (help compiling all requirements onto a minimal set of features (maybe formal description of the problem spaces, finding missing pieces when coming from an OO background, ..), or implementing parts of the system).<br />
<br />
Difficulty: generally rather hard <br />
<br />
Required skills: (Gambit), functional programming, metaprogramming, (OO programming)</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=User:Pflanze&diff=97User:Pflanze2008-03-13T00:00:34Z<p>Pflanze: remove chjmodule reference</p>
<hr />
<div>Realname: Christian Jaeger<br />
<br />
Projects: <br />
<br />
* [[Module_System]]<br />
<br />
Links:<br />
<br />
* [http://scheme.mine.nu scheme.mine.nu]</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Module_System&diff=96Module System2008-03-12T23:44:27Z<p>Pflanze: First version</p>
<hr />
<div>This is a project to create a module system primarily for the Gambit Scheme system. It does not have a real name yet.<br />
<br />
The system is meant complementary to the [[Snow!]] package system: unlike Snow!, this project does *not* focus on distribution, but instead it has the following objectives: <br />
<br />
* good interactive development capabilities (like runtime inspection and modification, included build system for the base case)<br />
* good code modularity features (parametrization, macros (hygiene, ..), and probably more)<br />
* generality (run code written in different language styles, to some extent in different module philosophies, interface with OO systems, host languages requiring translation like lazy variants of Scheme or maybe different languages like Arc or XSLT)<br />
* efficiency (employ cross-module inlining, parametrization specialization)<br />
* possibly achieve (partial) portability by moving parts into or building parts on top of the Snow framework (maybe not achieving the same level of integration with the host system, but at least make modules written by users portable to other Scheme systems)<br />
<br />
The projects wants to deliver a base system usable for everyday use quickly, and explore the more advanced objectives in the longer term.<br />
<br />
One essential part of the task involves getting to know the Gambit internals well enough to be able to embed the system well. Another essential one is laying a sound foundation especially for syntax handling (macros), considering the limited knowledge of the current contributors, this involves finding the right literature and people to query.<br />
<br />
During a first phase, the project will draw from (and may for some time continue to develop in) the code bases of the [http://scheme.mine.nu/gambit/chjmodule chjmodule] and the [http://scheme.mine.nu/gambit/jlongster/gambit-modules/ gambit-modules] projects.<br />
<br />
==Contributors==<br />
<br />
* [[User:Pflanze|Christian Jaeger]]<br />
* James Long<br />
<br />
==Google Sommer of Code==<br />
<br />
This project is attempting to participate in the [[GSoC_ideas_list|Google Sommer of Code]] campaign and intends to accept one student as additional core contributor.</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=User:Pflanze&diff=94User:Pflanze2008-03-12T22:55:16Z<p>Pflanze: My homepage</p>
<hr />
<div>Realname: Christian Jaeger<br />
<br />
Projects: <br />
<br />
* [http://scheme.mine.nu/gambit/chjmodule chjmodule] / [[Module_System]]<br />
<br />
Links:<br />
<br />
* [http://scheme.mine.nu scheme.mine.nu]</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Namespaces&diff=32Namespaces2008-02-10T16:30:40Z<p>Pflanze: Another small edit</p>
<hr />
<div>==== Namespaces ====<br />
<br />
=== Introduction ===<br />
<br />
Gambit is implementing a namespace mechanism, which is being used to separate internals from user code and also to partition the Gambit internals into several parts (e.g. the compiler parts are using a different namespace than the interpreter parts).<br />
<br />
The namespace mechanism is not described in the official documentation, but it is being used and hence shown in the examples bundled with the Gambit source code. Marc maybe didn't officially document it since he didn't want to sanction it as official mechanism that he would need to support into the indefinite future, and he maybe originally just wrote it for his own purposes (those is just speculations). In the mean time, as there is now an "official" module system in the form of SNOW!, users can also be encouraged to make use of the latter instead of using the namespace mechanism directly (the writer of these lines also intends to continue to work on his "chjmodule" module system to further explore dynamic programming and other concepts like parametrization).<br />
<br />
=== How does it work? ===<br />
<br />
There is a special rule for fully qualifying an identifier, and there is a special form which can be used to (a) declare the currently active default namespace, and (b) to declare a list of given identifiers to be in a particular namespace.<br />
<br />
==== Full qualification ====<br />
<br />
Gambit is treating the # character (#\# in Scheme syntax) in identifier symbols as a special character separating the namespace from the local name. Example:<br />
<br />
foo#bar<br />
<br />
is the <code>bar</code> identifier in the "foo#" namespace (I include the # separater character here since that's also how the namespace form works and because that allows to specify the empty namespace).<br />
<br />
There are two special namespaces, one is the "#" namespace being used for most basic internals, and the "" (empty) namespace being the default namespace for user code when the Gambit interpreter or compiler is being started.<br />
<br />
==== Declaring an identifier as belonging to a particular namespace ====<br />
<br />
The<br />
<br />
(namespace (STRING SYMBOL...))<br />
<br />
special form specifies that the list of the given identifiers (symbols) are to be treated as belonging to the namespace given in STRING. Example:<br />
<br />
(namespace ("foo#" bar))<br />
<br />
says that whenever <code>bar</code> is being mentioned in the code that follows in the same scope or file, it is implicitely being treated as <code>foo#bar</code>.<br />
<br />
Note that the identifier <code>namespace</code> is part of the empty namespace. If you change the default namespace (see below), you have to use <code>##namespace</code> instead.<br />
<br />
==== Switching the default namespace in code ====<br />
<br />
Identifiers which are not containing a # character are being treated as belonging to the namespace being active in the current scope (see below for what the scope is). This is the empty namespace by default. This can be changed by putting<br />
<br />
(namespace (STRING))<br />
<br />
before the rest of the code; e.g. using a namespace declaration without a list of identifiers. Note that once you've changed the default namespace, you cannot refer to <code>namespace</code> anymore, since this identifier is only being defined in the empty namespace and there is no way to fully qualify identifiers as belonging to the empty namespace, so you have to use the <code>##namespace</code> identifier instead (meaning the full qualification for the "#" internals namespace) which acts the same.<br />
<br />
==== Scope of namespace declarations ====<br />
<br />
A namespace declaration is in effect until the end of the current lambda or let construct (note that <code>begin</code> doesn't open a new scope), or, if specified at the top level of the file (or just inside a <code>begin</code> form residing in the top level) until the end of that file.<br />
<br />
==== Switching default namespace in the repl ====<br />
<br />
If entered in the repl, or run by the <code>eval</code> procedure, the default namespace used by the repl (which is also the empty namespace by default) is being changed. This then remains active until the next namespace declaration is being entered or eval'ed.<br />
<br />
=== Usage ===<br />
<br />
==== Modularization ==== <br />
<br />
The namespace mechanism can be used to partition user code in a style similar to how C works, by writing a "header" file for a library which declares all the exported values to be in the namespace that has been choosen for that library. In the Gambit source code and the examples, Marc is employing the convention of adding the # character to the name of the module (e.g. if he writes a module "foo.scm" he will name the header file "foo#.scm").<br />
<br />
==== Access to Gambit internals ====<br />
<br />
Since the namespace handling doesn't prohibit access (it's just for the sake of convenience, not for protection), Gambit is somewhat special in that all of its internal procedures can be accessed by the user; this is very useful to learn how the internals work and also to extend the system without hacking the Gambit source code. It must be noted though, that most of those procedures are not checking their types, so you will quickly get a segfault when feeding them data of the wrong type. Sometimes this missing type check is also (mis)usable (or even being used explicitely by other Gambit internal procedures) to access data structures on a lower level:<br />
<br />
(define-structure foo a b c)<br />
(let ((v (make-foo 123 "hello" 'world)))<br />
;; (mis)treat the structure as vector:<br />
(let ((len (##vector-length v)))<br />
(let lp ((i 0))<br />
(if (< i len)<br />
(begin<br />
(println "value at position " i ":" (##vector-ref v i))<br />
(lp (+ i 1)))))))<br />
<br />
This prints<br />
<br />
value at position 0:#<type #2 foo><br />
value at position 1:123<br />
value at position 2:hello<br />
value at position 3:world<br />
<br />
(Note that if you access elements behind the given length, you would access unrelated memory contents or invalid memory addresses.)<br />
<br />
==== Producing lowlevel unsafe code explicitely ====<br />
<br />
It's also worthwhile knowing that the basic primitives (like memory accesses, lowlevel arithmetic, etc.) which are mapped by the compiler directly to C constructs (actually C macros as defined in the include/gambit.h file) are a bunch of such identifiers in the # namespace. Like <code>(##car obj)</code> will be translated to <code>___CAR(obj)</code> which is then expanded by the C compiler to basically a pointer dereference. So those can be used in user code to let the compiler output those lowlevel constructs, which are not doing any type checking (and are simple enough for the C compiler to enable optimizations on the C level) and thus very fast, without declaring your whole Scheme code as being unsafe by using the <code>declare</code> special form (which would achieve the same thing).</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Namespaces&diff=31Namespaces2008-02-10T16:26:04Z<p>Pflanze: A few small fixes</p>
<hr />
<div>==== Namespaces ====<br />
<br />
=== Introduction ===<br />
<br />
Gambit is implementing a namespace mechanism, which is being used to separate internals from user code and also to partition the Gambit internals into several parts (e.g. the compiler parts are using a different namespace than the interpreter parts).<br />
<br />
The namespace mechanism is not described in the official documentation, but it is being used and hence shown in the examples bundled with the Gambit source code. Marc maybe didn't officially document it since he didn't want to sanction it as official mechanism that he would need to support into the indefinite future, and he maybe originally just wrote it for his own purposes (those is just speculations). In the mean time, as there is now an "official" module system in the form of SNOW!, users can also be encouraged to make use of the latter instead of using the namespace mechanism directly (the writer of these lines also intends to continue to work on his "chjmodule" module system to further explore dynamic programming and other concepts like parametrization).<br />
<br />
=== How does it work? ===<br />
<br />
There is a special rule for fully qualifying an identifier, and there is a special form which can be used to (a) declare the currently active default namespace, and (b) to declare a list of given identifiers to be in a particular namespace.<br />
<br />
==== Full qualification ====<br />
<br />
Gambit is treating the # character (#\# in Scheme syntax) in identifier symbols as a special character separating the namespace from the local name. Example:<br />
<br />
foo#bar<br />
<br />
is the <code>bar</code> identifier in the "foo#" namespace (I include the # separater character here since that's also how the namespace form works and because that allows to specify the empty namespace).<br />
<br />
There are two special namespaces, one is the "#" namespace being used for most basic internals, and the "" (empty) namespace being the default namespace for user code when the Gambit interpreter or compiler is being started.<br />
<br />
==== Declaring an identifier as belonging to a particular namespace ====<br />
<br />
The<br />
<br />
(namespace (STRING SYMBOL...))<br />
<br />
special form specifies that the list of the given identifiers (symbols) are to be treated as belonging to the namespace given in STRING. Example:<br />
<br />
(namespace ("foo#" bar))<br />
<br />
says that whenever <code>bar</code> is being mentioned in the code that follows in the same scope or file, it is implicitely being treated as <code>foo#bar</code>.<br />
<br />
Note that the identifier <code>namespace</code> is part of the empty namespace. If you change the default namespace (see below), you have to use <code>##namespace</code> instead.<br />
<br />
==== Switching the default namespace in code ====<br />
<br />
Identifiers which are not containing a # character are being treated as belonging to the namespace being active in the current scope (see below for what the scope is). This is the empty namespace by default. This can be changed by putting<br />
<br />
(namespace (STRING))<br />
<br />
before the rest of the code; e.g. using a namespace declaration without a list of identifiers. Note that once you've changed the default namespace, you cannot refer to <code>namespace</code> anymore, since this identifier is only being defined in the empty namespace and there is no way to fully qualify identifiers as belonging to the empty namespace, so you have to use the <code>##namespace</code> identifier instead (meaning the full qualification for the "#" internals namespace) which acts the same.<br />
<br />
==== Scope of namespace declarations ====<br />
<br />
A namespace declaration is in effect until the end of the current lambda or let construct (note that <code>begin</code> doesn't open a new scope), or, if specified at the top of the file (or just inside a <code>begin</code> form) until the end of the file is is being put into.<br />
<br />
==== Switching default namespace in the repl ====<br />
<br />
If entered in the repl, or run by the <code>eval</code> procedure, the default namespace used by the repl (which is also the empty namespace by default) is being changed. This then remains active until the next namespace declaration is being entered or eval'ed.<br />
<br />
=== Usage ===<br />
<br />
==== Modularization ==== <br />
<br />
The namespace mechanism can be used to partition user code in a style similar to how C works, by writing a "header" file for a library which declares all the exported values to be in the namespace that has been choosen for that library. In the Gambit source code and the examples, Marc is employing the convention of adding the # character to the name of the module (e.g. if he writes a module "foo.scm" he will name the header file "foo#.scm").<br />
<br />
==== Access to Gambit internals ====<br />
<br />
Since the namespace handling doesn't prohibit access (it's just for the sake of convenience, not for protection), Gambit is somewhat special in that all of its internal procedures can be accessed by the user; this is very useful to learn how the internals work and also to extend the system without hacking the Gambit source code. It must be noted though, that most of those procedures are not checking their types, so you will quickly get a segfault when feeding them data of the wrong type. Sometimes this missing type check is also (mis)usable (or even being used explicitely by other Gambit internal procedures) to access data structures on a lower level:<br />
<br />
(define-structure foo a b c)<br />
(let ((v (make-foo 123 "hello" 'world)))<br />
;; (mis)treat the structure as vector:<br />
(let ((len (##vector-length v)))<br />
(let lp ((i 0))<br />
(if (< i len)<br />
(begin<br />
(println "value at position " i ":" (##vector-ref v i))<br />
(lp (+ i 1)))))))<br />
<br />
This prints<br />
<br />
value at position 0:#<type #2 foo><br />
value at position 1:123<br />
value at position 2:hello<br />
value at position 3:world<br />
<br />
(Note that if you access elements behind the given length, you would access unrelated memory contents or invalid memory addresses.)<br />
<br />
==== Producing lowlevel unsafe code explicitely ====<br />
<br />
It's also worthwhile knowing that the basic primitives (like memory accesses, lowlevel arithmetic, etc.) which are mapped by the compiler directly to C constructs (actually C macros as defined in the include/gambit.h file) are a bunch of such identifiers in the # namespace. Like <code>(##car obj)</code> will be translated to <code>___CAR(obj)</code> which is then expanded by the C compiler to basically a pointer dereference. So those can be used in user code to let the compiler output those lowlevel constructs, which are not doing any type checking (and are simple enough for the C compiler to enable optimizations on the C level) and thus very fast, without declaring your whole Scheme code as being unsafe by using the <code>declare</code> special form (which would achieve the same thing).</div>Pflanzehttps://gambitscheme.org/wiki/index.php?title=Help:Contents&diff=27Help:Contents2008-01-31T18:39:41Z<p>Pflanze: Why has this page been missing? Link to the upstream website.</p>
<hr />
<div>See the [http://www.mediawiki.org/wiki/Help:Contents mediawiki documentation page].</div>Pflanze