Graphics Module


The Graphics module contains geometric and graphical software as a number of general utilities to support this.
  1. Functional error system.
  2. Parser for tokens and AST.
  3. Show and persistence frame work
  4. Immutable Array based collection system inlcuding flat Array[Int] and Array[double] based compound value collections of same length elements.
  5. Basic geometry.
  6. A number of implementation Value classes of the Int and Double product classes defined in ostrat.
  7. 2d graphical objects for generalised use. They are of particular use for the generic canvas based classes defined in pCanv but can be used in any display framework and for printing.
  8. ostrat.geom A pure or near pure functional package.
    • ostrat.pCanv depends on geom. This could be made into a separate module, but I don't see any great advantage.
      • Abstract canvas and classes for placing objects on that abstract canvas.
      • classes for the manipulation and display of maps.
      • Mouse and other abstract controls.
      • An implementation of Canvas for Jvm using JavaFx.
      • An implementation of Canvas for Html Canvas using JavaScript.
      • There is no implementation for Native yet. I'm waiting for Scala-native to get up on 2.12 before experimenting. Running a game server in native should pose no problems. However there is no easily accessible canvas for native on Windows or Linux. The abstract canvas api could be implemented on DirectX or OpenGL, but this would require significantly more work than for the ScalaFx canvas or the Html Canvas.


The Tokeniser will create the following tokens

KeyTokens, Identifiers, and literals are all expressions. Operators, seperators and comments are not. Identifers includes lexemes such as if, IF true and TRUE. There are no alphabetic keywords in RSON syntax. Consumers of RSON syntax can of course treat what ever identifers they want as keywords appropriate to their use case. Identifers are categorised into 3 types.

Numerical literals come in 4 types.

LetterChar = unicode_letter | '_'
NonZeroDigit = '1' ... '9'
DigitChar = '0' | NonZeroDigit
HexaLowerChar = 'a' ... 'f'
HexaUpperChar = 'A' ... 'F'
HexaLetterChar = HexaLowerChar | 'a' ... 'f'
HexaChar = DigitChar | HexLetterChar
LetterOrDigitChar = LetterChar | DigitChar
LetterOrUnderscoreChar = LetterChar | '_'
UnderscoreThenLetterOrDigit = '_', LetterOrDigitChar
Dot3Token = "..."
Dot2Token = ".."
DotToken = '.'

IdentifierToken = letter | UnderscoreThenLetterOrDigit, { LetterOrDigitChar | UnderscoreThenLetterOrDigit }
DeciLitToken = '0' | (NonZeroDigit { DigitChar })

Abstract Syntax Tree

So after the source has been tokenised it is parsed into an Abtract Syntax tree. the basic idea is that an RSON file can be three things.

  1. An unStatemented file. It just contains an expression, without a semi colon at the end for example could just an Int or String.
  2. A Statemented file
  3. The empty file. It may contain comments but no expressions. The empty statement is a thing in itself but also a special case of a claused statement with with zero Clauses.
  1. An unClaused Statement. It just contains an expression, without a comma at the end for example could just an Int or String.
  2. A Cluased Statement
  3. The empty Statement It may contain comments but no expressions. The empty file is a thing in itslef but also a special case of a Statemented file with zero statements.
So there is currently some confusion as to where it is parsed into a series of statements or into an expression. Currently Statements and Clauses contain an expression but are not themsleves an expression. This is causing a block to me coding at the moment.

AST Precedence From lowest to highest after brace block parsing.

Hexadecimal and Base32

Hexadecimal is written with Uppercase letters. Base32 is written with the digits followed by the upper case letters A to W, with the letters 'I' and 'O' missing.


A Lower case letter will be use after numerals in names.