This is the formal definition of structures in the programming library. When not using the web page interface to design the programs, components can be deployed to different parts of the library using these kinds of packages.
Generally, there are two formats in this kind of document:
- A YAML-like data typing, structuralization and containment format.
- A procedural instructional format that requires knowledge of language syntax.
The documentation containment format specifies different data that are contained in the library. The library is like a filesystem with folders and files. The YAML mapping keys are the folder/file names, and document content may be embedded in the mapping values to be loaded later as the program requires.
An individual, top-level object in the document specifies the folder structure, where sub-folders are separated by forward slashes (/), and also by the nested structure of the YAML mapping specification.
File (format) content type is specified by using a certain keyword in the name of the folder hierarchy, and indicates what kind of object the content will be in when loaded into the library:
documents -- binary or text data that has little typing information interfaces -- embedded YAML-like documents that have structural and typing
information but that are not yet loaded into the interactive domain.
activities -- the procedural language layer that have object and executable
semantics, which shall be defined later. Activities are the default file content type, so this kind of specification need not be used unless the default type has been changed.
So a file is a folder unless it has text content, in which it is an activity, or a type that is specified in the path using a keyword.
YAML-like document format:
Refer to the YAML specification for the general format. There are two particular differences in the programming configuration:
Embedded text content () can be specified using the double colon (::) at the end of a line for a mapping key, and everything indented under that key becomes text data (according to YAML indentation rules). Note that the | vertical bar syntax may be used, as well.
Objects can be further be typed using a syntax attached to the end of a mapping key. If there is any text content between two parenthesis ( and ) following a key on the same line, before the colon at the end of the line, the text in between is used to name the type that the object becomes when the document is loaded into the system. The text, known as the type name, can be separated by a dollar sign ($) to indicate the component group the type belongs to (on the left-hand side), and the sub-type that is part of that group that builds the internal object configuration. An empty group name or absent dollar sign indicates that a type in the default group association will be used:
my-object-name(group$type): 'this string will be built into a group.type object'
Object references (& and *) are not supported (although they might work).
Procedural language specification:
The activity language consists of a module of executable statements and subroutine definitions that have a syntax very similar to Python. Programs executed in this language are multi-tasked in the server, so the capability of any program is limited compared to a full Python program.
The language is an object-oriented, functional procedural language that implements all mathematical operations, and also runs permissively in the context of the user and cooperatively with all other programs. The object interface is centered around operators: member-access, mapping access, arithmetic, functional, and instance lifecycle. A program has access to a certain set of objects given by its creation system, and these are known as symbols. Symbols can be used to access other objects.
A program task can interact with this set of symbols (its environment) to do things relative to the system which contains it (and restricts it). These are known as 'natives'.
A program may not access an object's member whose name starts with an underscore. This is because system-level operations are coded on underscores, and an alternate naming scheme has been introduced of use instead.
The programming library can be accessed using a set of symbols that reflect the filesystem structure, which is the primary interface for creating (instantiating) objects.
create -- or $: Unlike Python, the language allows for the dollar sign to
be a part of symbolic identifiers. This native symbol allows for the instantiation of an activity in the library, which defines methods and operators possibly using the dollar sign to specify special functions.
The $ native can also be used to refer to a library component without instantiating it. Components in the library are specified using their filesystem name (a string), but using $ or 'library', can be referred to symbolically.
call -- Whereas create instantiates an object, call invokes a method on a
library activity without doing so.
symbols -- used to inspect which symbolic members are part of an existing
structure -- activates a document already loaded into the library by creating
its configuration in the active system.
source -- retrieves the text content behind the library program.
Other native symbols can be used to operate basic data objects using the language, as well as other system constructs (like user interactivity), but these are beyond the scope of this text.
Python classes are not supported by the language, however object types can be defined using the activity model:
Methods (subroutines) defined in the activity are available on each object instance created from that activity, and are bound to that object instance during their execution. Note that these methods may not necessarily need to be called as members (see 'call' native).
Subroutine (function definitions) are not first-class objects like in Python. They are encapsulated in an activity module.
The language does not allow decorators, variable or keyword arguments, with context syntax, lambda functions, slicing, tuple unpacking, generator, list or dictionary comprehensions, dictionary inlining or set notation, slicing, or trinary if-else-then syntax.
It does however, allow text to be embedded in its syntax, which may contain a configuration document or other data. Additionally, function definitions may be treated symbolically for design flexibility.
me/mobility: interfaces/overlay:: locationChange($method):: $('me/mobility/tracking/particle', me, origin) collapse($command):: for p in me.tracking: p.collapse(me) tracking: particle:: def init$(mobile, location): # (.location = location).tracking[mobile] + . t = defaultAttr(location).tracking(mapping) defaultItem(t)[mobile](sequence).append(instance) # mobile.tracking + . defaultAttr(mobile).tracking(sequence).append(instance) instance.location = location def collapse(mobile): for p in mobile.tracking: for o in p.location.tracking[mobile]: o.interact(mobile, instance) def interact(mobile, other): pass # interact with other particle.
So this package has four (or more) layers:
The package (document) definition, an activity type definition (instance lifecycle), an interface configuration structure which contains object types that express system interactive constructs, and a symbolic native access procedure for operating library components within the programming server.