Monday, May 31, 2010

Talking about ParaSail

In planning for a talk to be given about ParaSail at the upcoming AdaEurope conference in Valencia, Spain, it seemed useful to try to come up with a set of bullet points that summarize why ParaSail might be of interest.  Here is the first draft of those bullets:
  • Implicit parallelism
    • Parameters evaluated in parallel with "hand-off" semantics,
    • "for" loops unordered by default, must work to force explicit sequencing between statements; 
    • Can request explicit parallelism with "||" and "concurrent loop"
  • Both Lock-free and Lock/Queue-based concurrent data structures
    • Operations on concurrent data structures presumed unordered by default;
    • Can use "dequeue conditions" to control ordering for queued operations;
    • Can wait simultaneously on multiple queued operations, selecting first one that is ready to be dequeued to proceed.
  • Small number of concepts:
    • Module, Type, Object, Operation
    • You get a Type by instantiating a Module (all Modules are "generic").
    • You get an Object by instantiating a Type.
    • An Operation takes inputs and produces outputs; no up-level variables
      • Operation names generally usable without any prefix, presuming some input or output is of type defined by module enclosing operation definition.
    • Nesting of entities uses distinct syntax:
      • type::nested_entity
      • object.component
      • object.operation(...) equiv to operation(object,...)
  • No global variables and no aliasing of (non-concurrent) variables
    • Read-write access only via parameters; 
    • "Context" parameter provided to gain access to operating system, database, user, etc.
    • Compiler prevents aliasing between parameters using "handoff" semantics.
  • Encourages formal approach to software
    • Preconditions, Postconditions, Assertions, Subtype constraints all use consistent syntax:
      • {boolean_expression} 
      • c.f. {P}S{Q} in Hoare logic
    • Compile-time enforcement of assertions and all other language-defined "checks"
      • no run-time exceptions to worry about.
    • [[Expr]] notation (c.f. denotational semantics) used to define semantics of operations in terms of "universal" types.
  • Minimal need for pointers:
    • Generalized containers support indexing and aggregate syntax 
      • A[I], [X, Y, Z], ["abc" => M, "def" => N]
    • Expandable objects with optional back/encloser references
    • Pointers only to stable or concurrent objects
    • Safe region-based/object-based storage management.
  • Five kinds of literals, all usable with user-defined types.
    • Integer, Real, Character, String, and Enumeration.
    • Corresponding Univ_XXX type for each kind of literal with full run-time semantics.
    • Syntactically distinct from other names used for entities
      • 42, 3.1459, 'X', "Hello", #red
    • User-defined types can use literals
      • provide conversion operation from Univ_xxx type to allow use of literals 
      • provide conversion operation to Univ_xxx to allow "[[...]]" denotational semantics notation.
  • Declarations syntactically distinguished from statements
    • Allows intermingling of statements and declarations within a block
    • var X [: T] [:= Expr];
    • const K [: T] := Expr;
    • type T is [new] Queue<actuals>;
    • function F(A : P; B : Q) -> R;
    • [abstract] [concurrent] interface Queue<formals> is ...

1 comment: