The full Scheme number tower is supported:

Depending on the numeric library compiled into SISC, floating point numbers have either 32 or 64 bit IEEE precision, or arbitrary ^[2] precision. Regardless, SISC's complex numbers have floating point components of the same precision as the reals. Integers have arbitrary precision in all numeric libraries, and rational numbers are built with arbitrary precision components.

SISC's characters are double-byte wide. This means that they are capable of representing the full range of unicode characters. Unicode characters can be created with number->character; #\nnnnnn, where nnnnnn is an octal number in the range 000000 -> 177777; or #\uxxxx, where xxxx is a hexadecimal number in the range 0000 -> ffff. At least two zeros must be specified to distinguish from the '0' character when using an octal character literal. At least one zero must be specified to distinguish a hexadecimal character from the 'u' character.

SISC also provides additional named characters, to add to the Scheme standard's space and newline:

Formally, SISC's lexer modifies the R⁵RS grammar with the following productions for character literals:

<character> --> #\ <any character> 
     | #\u <uinteger 16> 
     | #\ <uinteger 8>
     | #\ <character name>
<character name> --> backspace | newline | nul 
     | page | return | rubout | space | tab
      

Characters are not compared with respect to the locale of the running system. Character comparison is equivalent to numeric comparison of the character value as returned by char->integer.

There are a number of reasons why a full Unicode system is non-trivial, especially within the framework of the R⁵RS string and character functions. Such a discussion is outside the scope of this document. Unicode compliant processing may be made available in the future as a library, however.

SISC's symbols are ordinarily case-insensitive. SISC maintains true pointer equality between symbols with like contents, unless the symbol is created uninterned. An uninterned symbol is one which is guaranteed to be pointer distinct from any other symbol in the Scheme system, even another with the same contents. Uninterned symbols can be generated with:

Uninterned symbols, while always pointer-distinct, may still be equal? to another symbol if its representation matches another.

<cased symbol> --> |<identifier>|
        

(eq? 'a '|A|) ; => #f
(eq? 'a '|a|) ; => #t
(eq? '|A| '|a|) ; => #f
          

Strings are built from Unicode characters, and are compared lexicographically in a manner derived from character comparison. In addition to using backslash to escape the double-quote (") character and the backspace character itself, SISC provides several escape codes to ease string literal construction.

A function is provided to determine if a given pair is a proper list.

SISC supports the length prefix method of creating Vector constants. For example, '#5(x) creates a vector constant containing five identical symbols. In addition, the length-prefix form is used when printing vectors, and if elements repeat at the end of a Vector, only the last unique element is printed. This form is referred to as the compact vector representation. The unprefixed form with all elements displayed is called the verbose representation.

Vectors are displayed differently depending on the call used. When called with display, in addition to the ordinary R⁵RS rules regarding the output of values displayed with display, the verbose representation is displayed. Using write, on the other hand produces the compact representation.

Displaying a vector with pretty-print may output either the verbose or compact representation of a vector. The behavior in this regard is controlled by the vectorLengthPrefixing configuration parameter (see the section called “Configuration Parameters”). If set to #t, pretty-print will emit the compact representation. If #f, the verbose representation is produced.

SISC supports boxes, a container for a Scheme value. Boxing is often used to implement call-by-reference semantics. Boxes are created and accessed using the following three functions:

In addition to the box function for creating boxes, SISC provides an external representation for boxes and boxed values. It extends the R⁵RS grammar with the following:

<boxed value> --> #&<datum>
      

This syntax denotes a boxed value, with <datum> as the contained value.

Boxes are a distinct first class type. The box? predicate tests a value to see if is a box.

Boxes, like pairs, are only equal in the sense of eq? and eqv? when a box is compared with itself. A box is equal to another in the sense of equal? if the value contained within the box is equal? to the value contained in the other.

A parameter is a named dynamic variable that is accessed through a function. The function, when given no arguments, returns the current value of the parameter. When given an argument, the value of the parameter is set to the provided value.

SISC's parameters are fully compatible with those specified by SRFI-39. Consult the SRFI-39 specification at srfi.schemers.org for documentation on how to construct and use parameters. SRFI-39 does not specify the semantics for parameters in the presence of threads. SISC's parameters bind into the dynamic environment, which means their semantics are defined based on the semantics of dynamic environments' interactions with threads, specified in the section called “ Scheme Thread Semantics ”.

SISC follows the R⁵RS recommendation of immutable list, string, and vector constants. Quoted lists and vectors are immutable. Attempting to modify elements in these constants will raise an error. String constants are immutable as well when created with symbol->string.

In addition to the single line comments of the Scheme standard, SISC supports both s-expression commenting and nested, multiline comments. An s-expression comment is used to comment out an entire s-expression. To do this, the sharp sequence #; is used. It extends the R⁵RS grammar with the following production:

<expression-comment> --> #;<datum>
        

The reader, upon encountering this sharp sequence, will read and discard the next datum. The expression commented out must still be a valid s-expression, however.

Nested, multiline comments are as defined in SRFI-30. Briefly, a multiline comment begins with the sharp sequence #| and ends with the sequence |#. The comment may contain nested comments as well. Unfortunately, this extension cannot be represented in a stateless grammar for the lexical structure.

In addition to the R⁵RS standard control features, two additional forms, when and unless, are supported by SISC.

SISC provides a hygienic macro system that fully conforms to the R⁵RS standard. The macro system is provided by the portable syntax-case macro expander. In addition to R⁵RS macros, the expander provides a more flexible macro definition tool called syntax-case. A full description of the capabilities of the expander is best found in the Chez Scheme Users Guide , specifically Section 9.2, Syntax-Case .

In addition, SISC supports non-hygienic, legacy macro support in two forms; define-macro and defmacro. These forms, found in older Scheme code written for R⁴RS compliant Scheme systems, should be used only for executing legacy code which relies on it. New code should use the safer and more flexible syntax-case or the standard syntax-rules macros.

During the execution of any program, there is always a continuation that represents the rest of a computation. In addition, one can imagine all the activities that will occur as a result of an error. This sequence of actions is explicitly represented in SISC as a failure continuation.

Two values must be applied to a failure continuation. The first is an error record, a datastructure which describes the error (and may contain information about the name of the function that generated the error, a descriptive message about the error, etc.). The second is the continuation of the expression that raised the error. All errors raised in SISC automatically and implicitly obtain and apply these values to the active failure continuation. Applying the error record and error continuation to the failure continuation will not return to the continuation of the application, unless that continuation was captured and later invoked in a non-local entrance.

An error record is the value usually propagated with an error in SISC. It is a datastructure containing such information as the location of the error, a descriptive message about the error, and possibly other error metadata.

(throw (make-error))
; => Error.

(throw (make-error 'foo))
; => Error in foo.

(throw (make-error "something ~a happened" 'bad))
; => Error: something bad happened

(throw (make-error 3))
; => Error: 3

(throw (make-error #f 'foo))
; => Error: foo

(throw (make-error 'foo "something ~a happened" 'bad))
; => Error in foo: something bad happened
          

(with-failure-continuation
  (lambda (m e)
    (throw (make-nested-error 
            (make-error 'foo "could not call bar.") m e)))
  (lambda ()
    (error 'bar "something went wrong.")))
;=> Error in foo: could not call bar.
;   Caused by Error in bar: something went wrong.
          

(define (throw error . args)
  (call-with-failure-continuation
     (lambda (fk)
       (if (null? args)
           (call-with-current-continuation (lambda (k) (fk error k)))
           (fk error (car args))))))
          

(define (error . args)
  (throw (apply make-error args)))
          

At this point, a few examples may be helpful:

(+ 1 (/ 1 0) 3)
; => A divide by zero error is raised
	

(with-failure-continuation
    (lambda (error-record error-k)
      'error)
  (lambda () (+ 1 (/ 1 0) 3)))
; => The symbol 'error
	

(with-failure-continuation
    (lambda (error-record error-k)
      (error-k 2))
  (lambda () (+ 1 (/ 1 0) 3)))
; => 6
	

(with-failure-continuation
    (lambda (error-record error-k)
      (throw error-record error-k))
  (lambda () (+ 1 (/ 1 0) 3)))
; => A divide by zero error is raised
	

(with-failure-continuation
    (lambda (error-record error-k)
      (throw (make-error '/ "could not perform the division.") error-k))
  (lambda () (+ 1 (/ 1 0) 3)))
; => An error is raised: Error in /: could not perform the division.
	

(with-failure-continuation
    (lambda (error-record error-k)
      (error 'example-function "could not evaluate the expression."))
  (lambda () (+ 1 (/ 1 0) 3)))
; => An error is raised: Error in example-function: could not evaluate the expression.
	

Note that the difference between Example 3.6, “Propagate a different error with the same error continuation” and Example 3.7, “Raise a new error” is that in the former, the computation can still be restarted from the second argument of the addition if an outside handler catches the newly raised exception and applies the continuation. This is not true in the last example, as its a new error whose continuation is the same as the with-failure-continuation expression.

R⁵RS does not specify the behavior of dynamic-wind in the case where an error is raised while evaluating the during thunk. SISC chooses to view an error raised in that section as an instance of the dynamic extent being exited. In other words, if an error is raised in the dynamic extent of a dynamic-wind expression, SISC will ensure that the after thunk is evaluated before the error is propagated to the failure-continuation of the dynamic-wind expression.

(define x 0)
(dynamic-wind (lambda () (set! x (+ x 1)))
              (lambda () (/ 1 0))
              (lambda () (set! x (+ x 1))))

; => A divide by zero error is raised, and the value of x is 2
        

If an error is raised in either the before or after thunks, no additional measures are taken. The error is propagated to the failure-continuation of the dynamic-wind as if the dynamic-wind call was an ordinary function application. Explicitly, if an error is raised from before, neither during nor after will be executed. If an error is raised in after, the results of evaluating before and during remain valid.

Also noteworthy is what happens if a continuation is invoked that exits from either the before or after thunks. Such a case is treated just as if a continuation was invoked during the evaluation of an operand to an application. This is to say that no additional steps will be taken by SISC. If before is escaped by a continuation invocation, neither during nor after will be executed. If after is escaped, the results of before and during remain valid.

In summary, extraordinary evaluation is only possible during the evaluation of the during thunk. The before and after thunks are evaluated with the dynamic environment and dynamic-wind stack of the call to dynamic-wind itself.

Access to symbolic environments is performed through the getprop and putprop functions. All symbolic environment operations are thread safe.

Symbolic environments are a first class datatype in SISC. The top-level environment itself is merely a special cased symbolic environment. To obtain the top-level environment as a first class value, one can use the interaction-environment function that is an optional procedure in R⁵RS. Another useful environment is the R⁵RS report environment available by calling:

(scheme-report-environment 5)
        

Each call to scheme-report-environment returns a new environment that contains only the bindings available in the Scheme report. Finally, the initial environment available to the programmer when SISC starts can be retrieved using the sisc-initial-environment function:

Like scheme-report-environment, each call to sisc-initial-environment returns a distinct environment which contains only the bindings initially available when SISC starts. An interesting use of this would be to define one or more distinct initial-environments, bound to toplevel variables. One could then define Scheme code and data in each environment that can use the full SISC language but cannot see any bindings in other environments.

Finally, R⁵RS states that it is an error to modify the contents of a top-level variable that has not yet been created. SISC adheres to the standard, and raises an error when any unbound variable in a symbolic environment (including the top-level) is modified using set!. This differs from some Scheme systems that will silently create the binding and set it to the new value.

SISC contains a mechanism for creating a symbolic environment which is chained to another environment, such that new and modified bindings are created in the new, child environment, but bindings may also be resolved from the parent if not present in the child. SISC uses this functionality to protect the contents of the R⁵RS and SISC initial environments from modification. One can use it in a similar way, protecting the bindings in the parent for sandboxing or other purposes.