Graphics Module

Contents

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.

Tokeniser

The Tokeniser will create the following tokens

• Keytokens _ ? ?? ???
• Identifiers alphanumeric tokens starting with a letter or underscore character.
• Operators
• numeric literals
• Seperators , . .. ... { } etc.
• String literals
• Character literals
• Comments

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.

• IdentUnder An identifer beginning with an underscore character
• IdentLow And identifer beginning with a lower case alphabetic character.
• IdentUp An identifer beginning with an upper case alphabetic character. Some of these tokens will also be consider valid raw Base32 tokens, and a subset of these will also be considered valid raw Hexadecimals, however all the alphabetic characters must be lower case.

Numerical literals come in 4 types.

• Floating point numbers 6.02e23 6.02e-23 6.02e-23d.Note this is the only case where a negative or dash character is included as part of a token. Can have optional trailing lower case alphabetic characters at the end of the token.
• Explicit hexadecimals 0x433A 0x2222 0xff000bc Alphabetic characters must be all lower or all upper case.
• Explicit Base32 tokens 0y433G 0x222C 0yWW000MP Alphabetic characters must all be upper case.
• DigitCode tokens. These are a sequence of one or more sequences of digits separated by decimal points, as well as integer and fractional decimal numbers they can be used for version numbers, IP addresses and other codes. These can themsleves be further divided into
  • Valid natural integers 0 21 567 These are valid raw hexademimal and raw Base32 tokens.
  • Valid natural integers with trailing lower case alphabetic characters at the end of the token 0f 21snap 567d. These may be valid raw hexadecimal or Base32 tokens if the alphabetic letter all fall within the correct set of letters.
  • Raw Hexadecimals that start with a digit, the alphabetic characters must be all lower or all upper case. 3A 2d1e 567D. These are also valid raw Base32 tokens.
  • Raw Base32 tokens that start with a digit that are not valid raw Hexadecimals, the alphabetic characters must be all lower or all upper case. 3G 2d1s 567R
  • Valid fractional decimal numbers, which may have trailing lower case alphabetic characters at the end of the token 0.0f 2084.4 3.1rc
  • DigitCode Tokens with 3 or greater digit sequence parts 2.13.4 0.0.3snap 192.168.1.1
  There are no tokens for negative numbers. -5 -5.32 -5.87e7 -0xA434 will all be lexically processed as pairs of tokens.

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.

• SemicolonToken Delimits the end of a Statement. The last Statement of a block /file may have, but does not need a need a trailing Semicolon. A statement without commas is considered Unclaused.
• CommaToken Delimits the end of clause. The last Clause of a Statement may have, but does not need a trailing Comma, unless it is a single Clause Statment in which case it must have a trailing Comma to distinguish it from an Unclaused Statement.
• assignment operators. == and != are normal operators. Any other operators ending with a '=" character are assignment operators.
• The single Colon Token
• | From here on down the precedence is determined by the first character of the operator. An operator ending in a ':' will be expected to be an infix operator dispatch from its rhs.
• ^
• &
• = !
• :
• + -
• * / %
• All other special charachters
• Whitespace

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.

Miscellaneous

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