Soml parser (outdated, not used)
Go to file
Torsten Ruger 58b3553251 forgot gemfile 2015-10-07 15:04:54 +03:00
lib add class_fields as separate syntax 2015-09-27 12:05:35 +03:00
test add another simple function test 2015-10-06 00:22:18 +03: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 the new inspect 2015-09-19 14:40:08 +03:00
Gemfile.lock forgot gemfile 2015-10-07 15:04:54 +03:00
LICENSE Initial commit 2014-06-04 19:27:53 +03:00
README.md upped version, would be a major version if it were over 1 2015-10-07 15:04:23 +03:00
Rakefile using raketasks 2015-05-03 22:58:33 +03:00
salama-reader.gemspec upped version, would be a major version if it were over 1 2015-10-07 15:04:23 +03:00

README.md

Build Status Gem Version Test Coverage

Salama Reader

The parser part of salama is now a standalone gem. It parses Phisol using Parslet and no other dependencies.

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

Phisol Phi System Object Language

Phisol is just forming after realizing the (unfortunate) need for an oo system language. (I really didn't want to do yet another 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

From these comes the name: A phi node is the opposite of what you may think of as an if. Actually an if statement is always a branch (the if part) and a rejoining of the two branches (the phi part).

In Phisol 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 Phisol are just forming, but some things are clear:

  • statically typed (in the beginning with just two types) meaning all variable declarations, functions and arguments shall be typed.
  • objects but without data hiding
  • probably nil objects
  • static blocks (a bit ala crystal)
  • call syntax as already discussed, ie message based

Some things we shall leave behind from the ruby approach are a lot of sugar, like missing brackets, random code everywhere, expressions galore . . .

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
  • expression is a helper for all code allowed in a function
  • function definition must have braces too
  • keywords is just a list of them
  • operator expression 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.