jMax IRCAM - Centre Georges Pompidou

Basic Types



Symbols

Symbols are opaque types uniquely representing a string; the symbol name is the string corresponding to the symbol; two symbols whose names are equal (i.e. for which the strcmp function return 0) are the same symbol (i.e. == between them will return true).

Symbols are created from a string with dedicated functions; in order to avoid duplicating static strings, the default version, fts_symbol_new, will store a pointer to the string passed as argument; a special version, fts_symbol_new_copy, must be used when the string passed as argument cannot be shared, like in the case of a local buffer; using the first version with a pointer to a local, changable buffer, can result in any kind of behaviour, including memory corruption and system crashes.

Symbols include support for two non-visible functionalities: symbol caching in the communication with the kernel, and operator identification in expression evaluation; see the relative chapters for details.

The symbol.h file define a set of C variables for the symbols used in the FTS kernel, to avoid calling the fts_symbol_new function at run time; all the C variable symbols defined in the kernel should be defined here.

The implementation of the symbol table use a home made hash table of linked list of symbols, with a simple hashing function on symbol names.

As in many other case in the FTS kernel, most of the symbol access function are actually macro, so they cannot be called thru pointers.

Words

In many places FTS need to represent generic data of etherogeneous types; two basic mechanisms are provided, words and atoms; a word (type fts_word_t) is an union of the interesting basic C type; they include int and float, symbols, pointers to void and pointer to function returning void; note that types that tipically need 64 bits (at least on a 32 bit machine) as double are not included; a set of macros allow to set and get values of different types without the need of knowing the concrete definition of the fts_word_t type.

Note that words do not really intend to be the FTS generic type mechanism, but only the basic implementation for a value or a reference value in a more complex type system; see below.

Atoms

An Atom is a type tagged value; atoms are the standard way to represent, and pass values to functions and methods in FTS; they are also the basic unity of communication between FTS and the graphical clients.

There are two kind of values: basic, scalar values and reference types; scalar values are int, float and symbols, booleans and void values; reference types are type tagged pointers to other entities; currently, those entities can be strings, fts objects, ftsconnections, data, atom_array and void * pointers; see the other chapter for details on each type; some of these types are supported essentially for the sake of communication with the client, and others as a support to the message system; a number of macros allow atoms manipulation; the internal structure of a atom should never be accessed directly, because it can change (and it does change) between different releases.

The module provide a small set of basic functions, like test for equalities and printing and formatting functions.

Type tags are implemented as symbols, but we plan a short term introduction of a new type descriptor data type.

The most essential thing to understand about atoms is that while they bring some resemblance, and bring naturally to thing they are a basic MAX language feature, and the basic mechanism for building a power type system in FTS, actually they are *not*; for the moment, they are an implementation technique, in order to represent and refer conveniently to a number of vastly different data types (like fts objects, representing a statement in the MAX language, or a integer, representing a datum in the MAX computation, or again the whole content of an object like explode that is actually the private state of an object, exported to an editor on the client side), in vastly different situations (like editing a patch, executing a patch, editing a sequence); they are also used to represent the data used in the execution of a patch, so they are also used to implement the MAX language features, but there is no equivalence between the two, and assuming this equivalence will bring to a failure.

Conceptually defining this equivalence, and finding the proper way to implement it without changing the MAX language paradigm, and without cutting compatibility with existing patch is one of the most time consuming brainstorming activity of the jMax developement team.

Related Files

  • mess_types.h
  • words.h
  • atoms.c
  • atoms.h
  • symbols.c
  • symbols.h