Monday, September 28, 2009

Modules in ParaSail

Since ParaSail doesn't really exist at this point, I should probably write everything in the future tense. But instead I will use what my friends call the software present tense which is used to describe how it ought to work and hopefully will work someday, if that day ever comes...

Another thing I am somewhat uncomfortable with is using the first person ("I") so much in this description, so I will probably use "ParaSail" as the subject rather than "I" in many sentences. "We" seems a bit presumptious, though in a scholarly paper seems better than "I", even for a solo researcher. But in a programming language description, one really hopes that the language quickly comes to exist independently of any creator or creators. So (more than) 'nough said. On to the technical content:

ParaSail has only two kinds of modules: interface modules and class modules. A class module implements one or more interface modules. Perhaps a class ought to be called an implementation module, but that is an awfully long word, and in many ways a class module matches what languages like Simula and C++ and Java and C# and Eiffel call a class. In general ParaSail tries to use familiar terminology in familiar ways. Of course there is danger of confusion, but hopefully the benefits of familiarity outweigh the dangers of confusion.

Both interface and class modules are parameterized, essentially generic templates, as used in Ada, C++, Java, etc. Because of their wide-spread adoption, ParaSail uses "<...>" for generic parameters. While we are talking about notation, ParaSail uses "(...)" for normal function/procedure parameters, uses "[...]" for selecting from an array or similar container. ParaSail uses words for bracketing control flow (e.g. "if ... then ... else ... end if;"). ParaSail uses "{...}" for annotations such as constraints, assertions, pre/post-conditions, etc. This is intended to be familiar from Hoare logic, which uses the notation "{P} S {Q}" to represent a statement S with precondition P and postcondition Q.

Interface modules have the following basic syntax:
    interface name < generic_parameters >
    end interface name;
The interface_items comprise a sequence of function, procedure, and nested interface specifications. In addition constants and variables may be declared, but these are considered equivalent to corresponding functions. A constant is equivalent to a parameterless function returning an object of the constant's type. A variable is equivalent to a function with one by-reference parameter of the enclosing interface type, returning a by-reference object of the variable's type.  In addition, operators may be declared.  Operators are essentially functions with special syntax for calling them.

As subtly implied above, an interface defines a type, and within the interface module, the interface's name represents that type. A type is essentially an interface that has been bound to a set of actual generic parameters.  There are also subtypes in ParaSail, which are types with some additional constraints (such as a range limitation), specified inside "{...}".

Generic parameters are themselves either types derived from specified interfaces, or static constants used to parameterize the implementation of the interface, and/or select among different implementations of the same interface. A generic array interface, with its generic parameter list, might look like this:
 interface Array < Element_Type is Assignable<>;
                    Index_Type is Discrete<>>
   function First(Arr : Array) -> Index_Type;
   function Last(Arr : Array) -> Index_Type;
   function Element(Arr : ref Array;
     Index : Index_Type {Index in First(Arr)..Last(Arr)})
       -> ref Element_Type;
   function Create_Array(First, Last : Index_Type)
       -> Result:Array
           {First(Result) = First & Last(Result) = Last};
 end interface Array;
Note that there is no implicit parameter in ParaSail (identified as this or self in many object-oriented languages).  All parameters are explicit.  More about this example in the next installment.

No comments:

Post a Comment