Soml parser (outdated, not used)
Go to file
Torsten Ruger 56a02bd6ea use ast that produces ruby output 2016-12-08 19:34:59 +02:00
lib fix if false logic 2016-03-07 11:51:58 +02:00
test move to typed structure 2016-03-06 09:40:41 +02:00
.gitignore merged the origin 2014-06-04 19:49:40 +03:00
.travis.yml add cc token 2015-07-18 13:10:00 +03:00
Gemfile use ast that produces ruby output 2016-12-08 19:34:59 +02:00
Gemfile.lock use ast that produces ruby output 2016-12-08 19:34:59 +02:00
LICENSE Initial commit 2014-06-04 19:27:53 +03:00
README.md renamed to soml-parser 2015-11-30 19:55:48 +02:00
Rakefile renamed to soml-parser 2015-11-30 19:55:48 +02:00
soml-parser.gemspec renamed to soml-parser 2015-11-30 19:55:48 +02:00
to_code.rb add cli for soml->s-exp 2016-12-08 18:54:27 +02:00

README.md

Build Status Gem Version Test Coverage

Soml Parser

The parser part of soml is a standalone gem to allow independent development. It parses Soml using Parslet and no other dependencies.

Also it is very educational, as it is very readable code, and not too much of it.

Soml: Salama Object Machine Language

Soml is Still forming after realizing the need for an oo system language.

The need comes from these three things:

  • a language is needed to translate to. Meaning a software layer is needed, but to understand how that layer works, a syntax is needed. Thus is born a language.
  • Upward compatible memory and calling conventions are needed
  • Multiple return addresses are needed

In Soml a function call is not necessarily a part of linear code. A call may return to several addresses, making the call more like an if statement.

Syntax

Syntax and semantics of Soml are described on the salama site

  • statically typed so all variable declarations, functions and arguments are typed.
  • objects but without data hiding
  • static blocks (a bit ala crystal)
  • call syntax as already discussed, ie message based
  • no semicolns and stuff, but not ruby either

Parser

The main parser per se is in parser/salama , but it just pulls in all the parts.

All the other files are ruby modules representing aspects of the parser. Most names are quite self explanatory, but here is a list:

  • basic_type defines just that. Strings, symbols, integers, floats , also comments and space
  • call_site is a function call. May be qualified, but currently must still have braches
  • compound types are hash and array definitions. Hashes still need curlies
  • control is if statement which still must have an else
  • statement is a helper for all code allowed in a function
  • function definition must have braces too
  • keywords is just a list of them
  • operator statement are binary operators (see also below). There's a surprising amount
  • return statement are straightforward
  • while still needs a do, though i think in ruby a newline is sufficient

Transform defines how the rules map to Ast objects.

Ast

The ast layer now uses the ast gem. That approach is to use a single class to represent all types of node and use a type symbol (instead of different classes)

This works well, and is much less work.

The following step of compiling use the same kind of visitor approach as before

Parslet

Parslet is really great in that it:

  • does not generate code but instead gives a clean dsl to define a grammar
  • uses ruby modules so one can split the grammars up
  • has support for binary operators with precedence and binding
  • has a separate transform stage to generate an ast layer

Especially the last point is great. Since it is separate it does not clutter up the actual grammar. And it can generate a layer that has no links to the actual parser anymore, thus saving/automating a complete transformation process.