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 ...