BALL

This page has three main sections. (Note that the listings could be empty.) more… Tip: Remember the back-button! And don't click the number on the left.

  1. The first item displays a term, URL, text or picture.
  2. Followed by a (still unordered) listing of statements about this subject. (for details follow ">"-link)
  3. Separated by a horizontal rule a "reverse" listing of statements referring to this item in object position.
BALL Initial Expression Language
3651 label > BAIL
757 is a > Programming Language
859 description >

It should be stressed that any language worth it's salt would do. After all a contract can always establish it's own language. The initial language must at minimum allow to invoke processing of the contract language.

For this reason we often nickname it the shebang-language.

Note the separation of duties: this language should be easy to reason in and results must be easy to repeat independent of state and context.

There is another, smaller language, the Core API to control effects. When an agent executes code to respond to a message, a script in this language is invoked to eventually produce the a response in the language of the Core API.

That's similar to the way Haskell has a pure expression language and the IO monad to handle all effects.


The initial default language is a subset of Scheme and DSSSL. More details and procedure index here.

Scheme is chosen as a substrate for several reasons:

  1. First class continuations and guaranteed tail-call optimization makes implementing other languages easy.
  2. Hygienic syntax extensions are a powerful tool, though few languages support them.
  3. Scheme is a minimal core language. Additional features belong to "policy", not the "core" language.

The pure subset was chosen because side effects must only take effect after transactions are agreed upon. Hence effects have to be hold back until this moment. This would come at a runtime cost, which we wanted to avoid at low level.


Random Notes

The rest of this memo hold some random notes, which need to go somewhere, but do not yet haven't found an adequate place to live.

Readability

Depending on circumstances s-expressions are considered a hardship to the human author. The implementation in BALL has supported indentation sensitive syntax ("Python-style") according to SRFI-40 for several years. Version 2 will support t-expressions and incorporate learned lessons from version 1. Both versions will be supported for the foreseeable future.

Versions

  1. default namespace or namespace http://www.askemos.org/2000/NameSpaceDSSSL

    This language parses s-expressions only. Otherwise same as the next version.

  2. default namespace or namespace http://www.askemos.org/2005/NameSpaceDSSSL/

    This language parses according to SRFI-49. Some issues (TBD: which?) with SQL, we want to change.

  3. http://www.askemos.org/2013/new-name/ – This version is is being worked on.

    This language parses according to SRFI-110. It will also incorporate backward incompatible changes derived from lessons learned from using version 1.

XML Equivalence

The syntax tree of Scheme expressions can be mapped to tagged lists. For the recipe see SRFI-110 "grouping and splitting": a distinguished symbol, \\ as first symbol on a line in the case of SRFI-110 and group in SRFI-49, is reserved for the semantics of no symbol. Lists in the Scheme input AST whose first element is a pair are represented by a pair of this distinguished symbol and the list in the resulting s-expression.

Tagged lists can be mapped into XML via SXML.

Round Trip Safety

The XML equivalence allows an almost complete *round trip": any Scheme expression may be mapped into XML and back to Scheme. After at most two steps of such a back-and-forth transformation the resulting structure is bit-for-bit equivalent to the input for that step.

In the first step however information is lost in the general case: comments are removed.

To streamline the cooperation of programs with the authors activity, there MUST be a pair of parsing/serializing (a.k.e read/write) operations, which will retain comment nodes.

A Possible Good Idea

It seems to be a good idea sometimes to have a markdown-alike processing run over the source code and only pass content (or attributes) from certain elements of the resulting AST into a t-expression reader.

This would allow to easily and rather intuitively adjust the syntax to the problem at hand. Comment section could easily be the default and only blockquote content evaluated as well as just the other way around. If (some of) the non-evaluated AST elements are included literally in the result, we would end up with a markup language.

In extension one could easily dispatch on the "coarse grained" XML AST to parse element content according to different languages.

So we already use markdown as editing syntax (e.g. when maintaining this text), post-process the result, store only the XML concrete syntax and serialize the XML into markdown upon request. More dispatching in the post-process would be a matter of single line change.

760 derived from > Scheme (programming language family)
758 Dublin Core Type > s-expression
759 Dublin Core Type > Markup Surface Syntax
1559 Dublin Core Type > SRFI 110

XSLTbL see also