2. Onyx Language Reference
Keywords: onyx

Next: 2.1 Objects Up: Contents Previous: 1.13 Debugging Contents Index

#
2. Onyx Language Reference

Onyx is a stack-based, threaded, interpreted language. Its closest relative is Adobe PostScript, followed by Forth. Experienced PostScript programmers should find most aspects of Onyx familiar, but there are significant differences that will prevent a knowledgeable PostScript programmer from programming in Onyx without first skimming this chapter. This chapter does not assume specific knowledge of other programming languages, so stands as a definitive reference for Onyx.

Onyx is different from most languages in that it is not compiled, but rather consumed. For example, there are mechanisms for creating the equivalent of named procedures that can be called at a later time, but behind the scenes, the code is actually being interpreted as it is scanned in such a way that an executable object is created. As such, Onyx is not suited for compilation, native or byte code. However, the language syntax is very simple and the scanner/parser is extremely fast. There is also an operator called bind that optimizes interpreted code execution to approximately the same performance level as would be expected of a byte code interpreter.

Onyx is implemented as a C library that can be embedded in other programs. Mechanisms are provided for extending the set of operators available. This manual only documents the base language; see application-specific documentation for any language extensions.

Following is a list of basic language features that are discussed in more detail later in this chapter:

- Stack-based. There are no named variables as in procedural languages. Operations are done using various stacks, so Onyx operations are coded in postfix order.
- Threaded. Onyx's threading uses the native POSIX threads implementation of the operating system (or GNU pth, if so configured).
- Interpreted. Onyx code is never compiled, but is instead interpreted as it is encountered.
- Garbage-collected. There is no need to manually track memory allocation, since the interpreter has an integrated automatic mark and sweep garbage collector.

Subsections

- 2.1 Objects
- 2.2 Syntax
- 2.3 Stacks
- 2.4 Standard I/O
- 2.5 Interpreter recursion
- 2.6 Error handling
- 2.7 Threads
  - 2.7.1 Implicit synchronization
  - 2.7.2 Explicit synchronization
- 2.8 Memory management
- 2.9 Regular expressions
- 2.10 Object-oriented programming
- 2.11 Dictionary reference
  - 2.11.1 currenterror
  - 2.11.2 envdict
  - 2.11.3 errordict
  - 2.11.4 gcdict
  - 2.11.5 globaldict
  - 2.11.6 onyxdict
  - 2.11.7 outputsdict
  - 2.11.8 sprintsdict
  - 2.11.9 systemdict
  - 2.11.10 threaddict
  - 2.11.11 threadsdict
  - 2.11.12 userdict
- 2.12 Class reference
  - 2.12.1 vclass
  - 2.12.2 mclass
  - 2.12.3 module
- 2.13 Module reference
  - 2.13.1 modclopt

Next: 2.1 Objects Up: Contents Previous: 1.13 Debugging Contents Index