The libtscore is a C++ implementation of Scheme interpreter mainly
designed for embedding, especially for embedding into ochusha.

The implementation is started by porting of TinyScheme-1.33 but
almost entirely rewritten from scratch.  The TinyScheme,
http://tinyscheme.sourceforge.net/, is itself a very small scheme
interpreter suitable for embedding.

The libtscore has many differences from the original TinyScheme.
Here is the brief summary.  It is in fact quite difficult to find
similarity between libtscore and TinyScheme but it is still true
libtscore is derived from TinyScheme and includes a little stuffs
just borrowd from TinyScheme.

- Garbage collector is changed to generational copying garbage
  collector.
- Interpreter is changed to use bytecode execution instead of direct
  execution of S expression.  To do so, bytecode compiler is also
  integrated.
- The libtscore uses direct value to represent small integer values
  and characters instead of always using real cell representation to
  reduce heap pressure.  Integer values that can be represented in
  bit-width of long in C++ minus 2 bits are represented as direct
  value.  Characters are always represented by direct value.
- Foreign object type is added.  It is intended to be used with
  foreign functions.
- API for foreign function implementation are slightly modified.
- Some utility functions that help C/C++ programs to call scheme
  functions are added.  Because I'm a C/C++ developer want to use
  scheme program as a *part* of C/C++ programs instead of using C/C++
  program as a part of scheme program.
- input-output-port is eliminated, since they aren't like any
  standards and I've never used them.
- R5RS styled macro facilities, i.e. define-syntax and letrec-syntax,
  are implemented, let-sytanx has not been implemented yet.  On the
  other hand, old styled macro system is completely dropped because
  the author don't know its syntax and semantics.
- Basic regular expression handlings are implemented natively using
  oniguruma.  You can write to make regular expression object like
  #/regexp/ or (string->regexp "regexp").  The literal regexp
  notation, i.e. #/regexp/, is a clone of Gauche's notation.
  At this time, we supply only a few functions to use regular
  expression.

  (regexp-match-positions #/foo/ "foo bar") returns ((0 . 3)) and
  (regexp-match #/foo/ "foo bar") returns ("foo").
  (regexp-split #/:/ "/bin:/usr/bin") returns ("/bin" "usr/bin").
  (regexp-replace #/:/ "/bin:/usr/bin:/usr/local/bin" ",") returns
  "/bin,/usr/bin:/usr/local/bin".
  (regexp-replace* #/:/ "/bin:/usr/bin:/usr/local/bin" ",") returns
  "/bin,/usr/bin,/usr/local/bin".

  These functions are expected to behave just like pregexp except for
  a few exceptions.
  a) Our implementation assumes strings are actually UTF-8 strings.
  b) `pattern' should be regexp object.  We don't allow U-regexp.  But
     we have literal representations of regexp like Gauche, so this
     restriction should not be a significant limitation.  Of course
     you may be able to define wrappers/macros that simulate pregexp.
  c) regexp-split with NUL pattern splits string into list of string
     each represent a character within the source string like
     pregexp.  Our implementation is consious on UTF-8 so that
     splitting of characters are applied not for octet boundary but
     for each boundary of UTF-8 encoding.

  There's many issues between multibyte strings such as UTF-8 and
  character type in Scheme, e.g. character should be unicode instead
  of partial octet of UTF-8 encoding?


************************************************************************
  The original TinyScheme by R.C. Secrist is said to be derived from
  MiniScheme-0.85 that is developed by Atsushi Moriwaki and maintained
  by Akira Kida.

  Our codes are completely different from them, but we studied how to
  make scheme interpreter from them.  So, we cannot forget about
  them!
************************************************************************
