The Racket repository
Go to file
dyb 2daf225cab committing a handful of changes, none of which should be particularly
controversial, unless I damaged something in the process of integrating
them with other recent changes.  the user's guide and release notes
have been updated as well to reflect the changes of interest to end
users.
- the body of load-library is now wrapped in a $pass-time with
  to show the time spent loading libraries separately from the time
  spent in expand.
    syntax.ss
- interpret now plays the pass-time game
    interpret.ss
- added compile-time-value? predicate and
  compile-time-value-value accessor
    syntax.ss, primdata.ss,
    8.ms, primvars.ms, root-experr*
- $pass-stats now returns accurrate stats for the currently timed
  pass.
    7.ss
- compile-whole-program and compile-whole-library now propagate
  recompile info from the named wpo file to the object file
  to support maybe-compile-program and maybe-compile-library in
  the case where compile-whole-{program,library} overwrites the
  original object file.
    compile.ss,
    7.ms, mat.ss, primvars.ms
- replaced the ancient and unusable bintar with one that creates
  a useful tarball for binary installs
    bintar
- generated Mf-install InstallBin (InstallLib, InstallMan) now
  correctly indirects through InstallPrefix if the --installbin
  (--installlib, --installman) configure flag is not present.
    src/configure
- removed definition of generate-procedure-source-information
    patch.ss
- guardian tconc cells are now allocated in generation 0 in the hope
  that they can be released more quickly.
    gc.c
- added ftype-guardian syntax: (ftype-guardian A) creates a new
  guardian for ftype pointers of type A, the first base field (or
  one of the first base fields in the case of unions) of which must
  be a word-sized integer with native endianness representing a
  reference count.  ftype pointers are registered with and retrieved
  from the guardian just like objects are registered with and
  retrieved from any guardian.  the difference is that the garbage
  collector decrements the reference count before resurrecting an
  ftype pointer and resurrects only those whose reference counts
  become zero, i.e., are ready for deallocation.
    ftype.ss, cp0.ss, cmacros.ss, cpnanopass.ss, prims.ss, primdata.ss,
    gc.c,
    4.ms, root-experr*
- fixed a bug in automatic recompilation handling of missing include
  files specified with absolute pathnames or pathnames starting with
  "./" or "..": was erroring out in file-modification-time with a
  file-not-found or other exception rather than recompiling.
    syntax.ss,
    7.ms, root-experr*, patch*
- changed inline vector-for-each and string-for-each code to
  put the last call to the procedure in tail position, as was
  already done for the library definitions and for the inline
  code for for-each.
    cp0.ss,
    5_4.ms, 5_6.ms
- the compiler now generates better inline code for the bytevector
  procedure.  instead of one byte memory write for each argument,
  it writes up to 4 (32-bit machines) or 8 (64-bit machines) bytes
  at a time, which almost always results in fewer instructions and
  fewer writes.
    cpnanopass.ss,
    bytevector.ms
- packaged unchanging implicit reader arguments into a single record
  to reduce the number of arguments.
    read.ss
- recoded run-vector to handle zero-length vectors.  it appears
  we're not presently generating empty vectors (representing empty
  groups), but the fasl format permits them.
    7.ss

original commit: 7be1d190de7171f74a1ee71e348d3e6310392686
2019-02-11 20:06:42 -08:00
.travis use uuid_generate on unix-like systems for S_unique_id 2018-09-19 10:19:03 -04:00
c committing a handful of changes, none of which should be particularly 2019-02-11 20:06:42 -08:00
csug committing a handful of changes, none of which should be particularly 2019-02-11 20:06:42 -08:00
examples Updated csug socket code to match that in examples folder 2018-06-18 09:28:53 -04:00
makefiles added uninstall target for Unix-like systems 2018-08-31 13:22:47 -04:00
mats committing a handful of changes, none of which should be particularly 2019-02-11 20:06:42 -08:00
nanopass@1f7e80bcff latest nanopass 2016-06-27 09:45:20 -04:00
release_notes committing a handful of changes, none of which should be particularly 2019-02-11 20:06:42 -08:00
s committing a handful of changes, none of which should be particularly 2019-02-11 20:06:42 -08:00
stex@3bd2b86cc5 - compile-whole-program and compile-whole-library now copy the hash-bang 2016-05-04 20:35:38 -04:00
unicode initial upload of open-source release 2016-04-26 10:04:54 -04:00
wininstall add PDB files for Windows 2018-09-07 16:56:33 -04:00
zlib@cacf7f1d4e updated zlib to latest version, version 1.2.11 2017-02-13 22:27:21 -05:00
.gitattributes Adding .gitattributes files to correct language stats 2016-10-12 11:47:53 -04:00
.gitignore Added generated docs and intermediate files to .gitignore 2017-10-14 12:32:44 -04:00
.gitmodules - compile-whole-program and compile-whole-library now copy the hash-bang 2016-05-04 20:35:38 -04:00
.travis.yml use uuid_generate on unix-like systems for S_unique_id 2018-09-19 10:19:03 -04:00
bintar committing a handful of changes, none of which should be particularly 2019-02-11 20:06:42 -08:00
BUILDING updated BUILDING to mention the --threads option along with a couple 2019-02-07 14:52:41 -08:00
CHARTER.md initial upload of open-source release 2016-04-26 10:04:54 -04:00
checkin changed copyright year to 2017 2017-04-06 11:41:33 -04:00
configure committing a handful of changes, none of which should be particularly 2019-02-11 20:06:42 -08:00
CONTRIBUTING.md - added custom install options. workarea creates an empty config.h, 2016-05-06 18:30:06 -04:00
LICENSE initial upload of open-source release 2016-04-26 10:04:54 -04:00
LOG committing a handful of changes, none of which should be particularly 2019-02-11 20:06:42 -08:00
newrelease Makefile-csug.in install target is now consistent with the project 2018-03-28 09:25:20 -07:00
NOTICE - updated version to 9.5.1 2017-10-11 19:57:53 -04:00
README.md Changed the travis-ci monitoring image to match the current brnach (master). 2018-04-09 21:47:03 -04:00
scheme.1.in spelling 2017-12-04 09:35:31 +00:00
workarea attempt to stabilize timing tests let-values source-caching 2017-10-29 17:48:43 -04:00

Build Status

Chez Scheme is both a programming language and an implementation of that language, with supporting tools and documentation.

As a superset of the language described in the Revised6 Report on the Algorithmic Language Scheme (R6RS), Chez Scheme supports all standard features of Scheme, including first-class procedures, proper treatment of tail calls, continuations, user-defined records, libraries, exceptions, and hygienic macro expansion.

Chez Scheme also includes extensive support for interfacing with C and other languages, support for multiple threads possibly running on multiple cores, non-blocking I/O, and many other features.

The Chez Scheme implementation consists of a compiler, run-time system, and programming environment. Although an interpreter is available, all code is compiled by default. Source code is compiled on-the-fly when loaded from a source file or entered via the shell. A source file can also be precompiled into a stored binary form and automatically recompiled when its dependencies change. Whether compiling on the fly or precompiling, the compiler produces optimized machine code, with some optimization across separately compiled library boundaries. The compiler can also be directed to perform whole-program compilation, which does full cross-library optimization and also reduces a program and the libraries upon which it depends to a single binary.

The run-time system interfaces with the operating system and supports, among other things, binary and textual (Unicode) I/O, automatic storage management (dynamic memory allocation and generational garbage collection), library management, and exception handling. By default, the compiler is included in the run-time system, allowing programs to be generated and compiled at run time, and storage for dynamically compiled code, just like any other dynamically allocated storage, is automatically reclaimed by the garbage collector.

The programming environment includes a source-level debugger, a mechanism for producing HTML displays of profile counts and program "hot spots" when profiling is enabled during compilation, tools for inspecting memory usage, and an interactive shell interface (the expression editor, or "expeditor" for short) that supports multi-line expression editing.

The R6RS core of the Chez Scheme language is described in The Scheme Programming Language, which also includes an introduction to Scheme and a set of example programs. Chez Scheme's additional language, run-time system, and programming environment features are described in the Chez Scheme User's Guide. The latter includes a shared index and a shared summary of forms, with links where appropriate to the former, so it is often the best starting point.

Get started with Chez Scheme by Building Chez Scheme.

For more information see the Chez Scheme Project Page.