Language Overview

Registered by Eike

This should become a short (two page) description of the Siml language.

Blueprint information

Status:
Not started
Approver:
Eike
Priority:
Essential
Drafter:
Eike
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
Accepted for trunk
Implementation:
Informational Informational
Milestone target:
None

Related branches

Sprints

Whiteboard

The Siml Language is a special purpose language to describe differential equations. The language looks somewhat similar to Python. The compiler outputs a Python module that solves (integrates) the differential equation numerically. It can be run as an independent program or it can be used as a library for more complex programs. The Numpy and Scipy libraries are used for numerical computations.

A nicely illustrated introduction can be found here:
http://freeode.berlios.de/index.php#example_session

== Language ==
- Syntax looks like Python syntax
-- The new syntax, which is documented nowhere, has Python type indentation for blocks.

- Object oriented, no plain old data types.

- Methods all have special "this" argument.
-- implicit lookup of "this.foo"; resolution order is: local variable "foo", "this.foo", global variable "foo".
-- Code with many formulas gets a lot more easy to read this way.

- Statically typed, however variable types are inferred in some common situations
-- Member variables need to be declarered with the "data" statement. Complete type information is needed.
-- Types of method parameters are inferred when a method is called. (Individual code is issued for each invocation of a method.)
-- Local variables of a method are created automatically when they are assigned, and their type is inferred.

- Class definitions, function definitions, data definitions are all templates in the C++ sense.

- Imperative, but statements can be reordered.
-- Reordering of statements makes life easier for non programmers, and it allows calling functions automatically.
-- Some languages (for example Gproms, Modelica) are declarative. This makes either the compiler very complicated, or a system of (algebraic) equations has to be solved multiple times for each time step. Solving a system of equations is slow, and introduces problems when there are several solutions of nonlinear equations. The problems to write reliable programs with Gproms seem to result from solving nonlinear equations.

- Statement to solve systems of algebraic equations.
-- In some rare cases finding a closed solution is difficult. In these situations a system of algebraic equations can be solved numerically. (This is equivalent of the declarative approach of Gproms and Modelica.)

- Special functions as interface to the solution algorithm (similar to Python "__init__")
-- There are special functions that are called by the solution algorithm:
--- Initial: called once at the beginning of the simulation. Used to compute parameters and initial values.
--- Dynamic: called repeatedly during the simulation. Computes the (first) derivatives of all state variables
--- Final: called once at the end of the simulation. For saving data and showing diagrams.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.