Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section titled GNU Free Documentation License preceding the index at the end of this document.

NodeBrain™ is a trademark of The Boeing Company. All other trademarks and registered trademarks referenced in this document are the trademarks of their respective owners.

NodeBrain is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

History

2005/05/13	Title: NodeBrain Language Reference Author: Ed Trettevik <eat@nodebrain.org> Publisher: The Boeing Company

	Release 0.6.3 · The content of this document has been moved from the NodeBrain User’s Guide to focus specifically on language syntax and semantics. · This document, like the software it describes, is a “prototype” version. Revisions will be made in response to user feedback. · Included module and skill declaration · Comma is required to delimit file names on the source command. This was done to support spaces in file names on Windows. · The semi-colon (“;”) may be used as a platform independent path separator when defining module paths. We still allow (“:”) on Unix/Linux. · The underscore (“_”) may no longer be used within a simple term. We have plans for using it as a special term separator associated with skill modules.

2006/04/01	Release 0.6.4 · The “-“ and “=” special symbol commands are now documented as a single command we call the “servant” command. This update includes new syntax for directing stdout to a file or the interpreter, stderr to a file or the parent log, and specification of a shell program or other program. · The “:” command has been included for writing to stdout. This is useful when NodeBrain is run as a servant. · Servant option –s –-servant added. This option assigns a new meaning to the –s option, which was previously associated with the –-solve option. · Chapter 10, Prefix Commands was renamed Special Symbol Commands. · The “+” special symbol command was removed from Chapter 10, Special Symbol Commands. It is now deprecated in favor of expert commands that start with a context identifier followed by “(“ or “:”. The is covered at the start of Chapter 9, Commands. · Chapter 8, Listeners - the unfinished CMD listener section was removed. The Servant skill module now provides this functionality. All “listener” objects will be deprecated in favor of skill modules eventually.

2006/04/18	Release 0.6.5 · The “:” command just introduced in 0.6.4 has been replaced by “^”. This change was made to avoid a conflict with our use of “:” for a remote context override in client sessions. · An %INCLUDE source file directive has been reintroduced as an alternative and probably eventual replacement for the SOURCE command. Because this command is interpreted within the symbolic context, a directive seems more appropriate.

Preface

This document describes the NodeBrain language. It is intended for application programmers familiar with concepts covered in the NodeBrain User Guide. If you are more comfortable learning by example, you should begin with the NodeBrain Tutorial and reference this document as needed. Although this is a reference document, we’ve made an effort to introduce topics in a logical sequence for those who choose to read it from front to back.

This document was constructed by pulling out selected chapters from the original NodeBrain User’s Guide without modification. Consequently, it may take a few revisions before all the content ends up in the appropriate document.

See www.nodebrain.org for more information and the latest update to this document.

Documents:

NodeBrain User Guide

NodeBrain Tutorial

NodeBrain Language Reference

NodeBrain Module Reference

NodeBrain API Reference

Document Conventions

We use a modified BNF (Backus Neur Form) notation to describe the syntax of the NodeBrain language, as illustrated by the following example.

Syntax:
	assertCmd	::= ( assert š \| ` ) [assertionList ] [ ; [ comment ] ] •

	assertionList	::= cellAssertion { , cellAssertion }

	cellAssertion	::= cellIdentifier ( = \| == ) cellExpression \| [ ! \| ? ] cellIdentifier

	cellIdentifier	::= identifier \| [ identifier ] ( [ cellist ] )

	cellList	::= cellExpression { , cellExpression }

Meta-symbols have a special meaning, except when in bold font where they represent themselves as symbol within the language.

::= is defined as

| or

( ) sub-expression – e.g. ( happy | sad ) day

[ ] optional expression – 0 or 1 – e.g. [ really ] happy

{ } repeating expression – 0 or more – e.g. { really } happy

“” literal string – e.g. “|”, “(“, “)”, etc. (prefer bold font)

We deviate from BNF in our distinction between terminal symbols and syntax rule identifiers. Instead of enclosing syntax rule identifiers between “<” and “>”,we use a different font for identifiers and terminal symbols.

expression Italics for syntax rule identifiers

assert Bold font for symbols of the language (terminal symbols)

When we want to emphasize the importance of “white space” or an “end of line” character, we use special symbols.

š White space identifier

• End of line identifier ( LF | CR | null character)

Sometimes we get a bit lazy and leave rule identifiers undefined if it seems obvious, or more often because they are defined elsewhere in the document. We also assume a terminating character does not exist within the construct it terminates. In the following example we assume no character is a quote.

“ { character } “

We also don’t bother to quote our literal quotes. Bold quotes with a space on both sides are literal quotes---symbols of the language, not meta-symbols. When quotes are used to convert a meta-symbol into a literal symbol, it is clear by the spacing and the font.

“{“ Literal brace

We are phasing out this use of meta-symbol quotes by simply using bold font to identify literals.

{ Literal brace

{ Meta-symbol

The following rules describe the syntax of our modified BNF.

Syntax:
	rule	::= identifier ::= expression

	expression	::= term { š \| š term }

	term	::= factor [ š term ]

	factor	::= identifier \| spaceIdentifier \| eolIdentifier \| terminal \| subExpression \| optionalExpression \| repeatExpression

	identifier	::= alpha { alpha }

	alpha	::= a-z \| A-Z

	spaceIdentifier	::= š Represents one or more space characters

	eolIdentifier	::= • Represents end-of-line character

	terminal	::= string \| “ string “ \| boldString

	string	::= character { character }

	boldString	String in bold font

	subExpression	::= ( expression )

	optionalExpression	::= [ expression ]

	repeatExpression	::= { expression }

In examples we sometimes use “…” to mean “blah blah blah” in a place that is not the focus of the example. You must replace “…” with valid syntax if you want to experiment with the example.

define r1 on(…) a=5;

define goldenRule on(others) …; # as you would have them do onto you

Sometimes commands that must be coded on a single line are shown as multiple lines in an example. This is indicated by one line ending with “ …” and the next line starting with “… ”.

define r1 on((a=5 and b=7) or (c=2 and d=17)): …

… {on(a=2);(mo,we,fr):-dir;}