design elements

Design Elements

The language will have the usual modular structure: - #namespace - #class - #function - #statement - #expression - #module - #rule / #predicate

It will wrap these concepts around the operational model of: - scope - environment - parameter - bindings

Being object-oriented, there will be concepts for: - this - methods

But they will just be a veneer atop more fundamental concepts. Chief amongst them is that the meaning of this is a graph. this is a reference (via #URI) to a #graph in the in-memory #triple store.

All state transformations that happen to an object are actually assertions and retractions to the underlying graph.

The language should aim to provide consistent semantics regardless of where the data is stored. i.e. it should work the same on in-memory data, remote data and should be as easy to stream in/out via stdin/stdout, via file streams or via, say, SPARQL.

All computational work should translate into: - assertions/retractions of triples to graphs - conventional expressions on literal data

One quite vital design requirement is that the language should be much more transparent than, say, an API that explicitly manipulates reified triples. i.e. the representation of a triple should be hidden by the syntactic sugar of the language.

Modules are imported once, into memory, regardless of how many times they feature in an import statement.