10A FORMAL SEMANTICS AND ANINTERACTIVE ENVIRONMENTFOR SISALIsabelle Attali,Denis Caromel,Andrew Wendelbornia@sophia.inria.frINRIA Sophia Antipolis - BP 93, 06902 Sophia Antipolis - Francecaromel@unice.frI3S Route des Colles BP 145, 06560 Sophia Antipolis - Franceandrew@cs.adelaide.edu.auDept. Computer Science, University of Adelaide 5005 - AustraliaABSTRACTWe present a formal de�nition of the dynamic semantics of a signi�cant part of thelanguage Sisal 2.0 in the structural operational style of Natural Semantics, using Ty-pol inference rules within the Centaur system, a generic speci�cation environment.Sisal is a strongly typed, applicative, single assignment language in use on a varietyof parallel processors, including conventional multiprocessors, vector machines anddata- ow machines.The motivations of our work are, with a formal semantic description of Sisal, toprovide a �rm foundation for understanding and evaluating language design issues,aid the elimination of ambiguities in the language, and provide a valuable referencefor both implementors and programmers. At the same time, Centaur speci�cation-s automatically yield a structure editor and an interpreter for Sisal, which can bedeveloped into an interactive environment for Sisal programming. Besides classicaldynamic semantic aspects of functional programming languages such as the absenceof side-e�ects and aliasing, the notion of referential transparency, and higher-orderfunctions, we have characterized speci�c semantic aspects of the Sisal language suchas arrays, in�nite streams, sequential and parallel loops.From this semantic de�nition, we intend to formally de�ne program transformations,particularly parallelization techniques and algorithms for Sisal compilation, and to in-corporate such techniques into a program development and visualization environmentfor Sisal programming.

230 Tools and Environments1 INTRODUCTIONWe present a formal de�nition of the dynamic semantics of a signi�cant part ofthe language Sisal 2.0 in the structural operational style of Natural Semantics;more precisely using Typol inference rules within the Centaur system, a genericspeci�cation environment.Sisal is a strongly typed, applicative, single assignment language in use on avariety of parallel processors, including conventional multiprocessors, vectormachines and data- ow machines. Sisal 1.2 [11] has been in use since 1984;Sisal 2.0 [3], a new language de�nition, is currently under development.Sisal research and use has demonstrated the e�ectiveness of the language andits implementation on a wide variety of applications and machines. The Opti-mizing Sisal Compiler (OSC) and other tools are freely available from LawrenceLivermore National Laboratory. The Sisal 2.0 proposal suggests inclusion (ina limited form for the sake of e�ciency) of features such as higher-order func-tions, polymorphism, overloading and type inference. Most applications im-plemented so far are scienti�c applications, which exhibit a regularity of dataand program structure most readily analyzed by the automatic parallelizationtechniques used in implementing Sisal.Another interactive environment for Sisal is proposed in [23, 24]; however boththe means and the objectives are di�erent from the work presented here. Re-garding the method, their system is not based on a formal description of Sisal,but rather on classical programming techniques, which explains itself with thefact that the intended goal does not include formal transformations or proofs,but instead focuses on scheduling and assessment.The work reported here is the �rst attempt to describe formally the dynamicsemantics of Sisal 2.0. We expect, with a formal semantic description of Sisal,to provide a �rm foundation for understanding and evaluating language designissues, aid the elimination of ambiguities in the language, provide a valuablereference for both implementors and programmers, and facilitate comparisonof Sisal with other parallel functional languages. In this paper, we describe thestructure of a Sisal 2.0 semantic de�nition and illustrate it with discussion ofmulti-valued expressions, higher-order functions, name scoping, loops, arraysand streams.The Centaur system is a formal tool to model and implement all aspects of pro-gramming languages. From the speci�cations of the syntax and the semanticsof a given language, one can automatically produce a syntactic editor and inter-

Formal Semantics and Environment for Sisal 231active semantic tools (type checkers, interpreters) for this language; we showthese in use as a program development environment for Sisal programming.Also, we provide animation tools to show which expression is being evaluated,environment changes during execution, and which semantic rule is being inter-preted. Natural Semantics descriptions have been extensively used to expressdynamic semantics of various languages [22, 19, 2], de�ne various translations[7], describe compiler optimizations [26, 16], and formalize the semantics of da-ta ow graphs [20, 9]. We have drawn on a natural semantic characterizationof Lassi [10], a preliminary investigation into the semantics of a small Sisal-likelanguage. Aspects of the development of a Sisal 2.0 compiler are described in[12].In the next two sections, we introduce the Centaur system and the Sisal pro-gramming language. We then outline the structure of the semantic de�nition,and discuss brie y the techniques used to model various important aspects ofSisal, illustrated with rules from the natural semantics. Finally, we present theinteractive environment we developed from the Sisal speci�cation: structureediting, execution, and visualization of the semantics.2 THE CENTAUR SYSTEM ANDNATURAL SEMANTICSIn using the Centaur system to construct a programming environment for agiven language, the �rst step is the speci�cation of syntactic aspects | theconcrete and abstract syntax of a given language. From this speci�cation,one can derive a parser that transforms the textual form of a program into astructural representation, an abstract syntax tree well-typed with respect tothe abstract syntax de�nition. An abstract syntax is the many-sorted algebraof well-typed terms over a set P , of sorts and a set O, of operators with theirsignatures on P . There also exists the reverse mapping, called pretty-printingor unparsing, that transforms a structural representation into a concrete layout.Semantic speci�cations are in a structural operational style, using the NaturalSemantics approach [18] and its implementation using the Typol formalism [8].The general idea of a semantic de�nition in Natural Semantics is to provideaxioms and inference rules that characterize semantic behaviors to be de�ned onlanguage constructs. Behaviors are expressed with typed sequents in a logicalstyle close to Natural Deduction [14] and Structural Operational Semantics[21]. Language constructs (abstract syntax operators) appear in a distinguished

232 Tools and Environmentsposition in sequents, called the subject. Subjects are used for typechecking,according to the type de�nition of the sequent called a judgement.Within Natural Semantics, a semantic de�nition is identi�ed with a logic andreasoning with the language is proving theorems within that logic. For example,given a set of rules and axioms (for all expressions of an object language) typedwith the judgement: ENV ` EXP : ENVwhich expresses that evaluation of a subject of sort Exp in a given state of sortENV yields a new state of the same sort ENV, one can answer the followingquestion : given an initial state s0 and an expression E, is there a �nal states such that the sequent s0 ` E : s holds ? Axioms and rules are used as aproof-theoretic tool to generate new facts (proof trees) from existing facts in anon-deterministic manner due to the relational presentation of the formalism.Thus there can be several proof trees for the same fact.A typical Typol rule from the Sisal dynamic semantics is shown below. Thisrule expresses that the semantics of a Sisal program, given a function name toexecute and its e�ective parameters, is a list of values provided that the functionactually appears in the program and the execution of the function body (giventhe binding between formal and actual parameters), results in this list of val-ues. As shown in this rule, sequents can refer to other sets (function de�nition,function execution) which makes it possible to structure the semantic de�nitioninto di�erent sets, each of them dealing with related objects.Descriptions in Natural Semantics have several advantages: semantic de�ni-tions are concise, mathematically precise and directly executable and determinehow a program behaves. Typol rules are easily translated into a set of Hornclauses, so Prolog is a natural tool for evaluation of Typol programs.function_definition(FNAME |- SYSTEM : true(),function_def(function_header(_,FOR_PARAMS,_), EXPS)) &bind_parameters(FOR_PARAMS, EFF_PARAMS -> BIND_PARAMS) &function_execution(SYSTEM, BIND_PARAMS |- EXPS : VALUES)------------------------------------FNAME, EFF_PARAMS |- SYSTEM : VALUES;Figure 1 A Typol rule.

Formal Semantics and Environment for Sisal 2333 OVERVIEW OF THE SISAL LANGUAGESisal is a strongly typed, applicative, single assignment language intended forus on a variety of parallel processors, including conventional multiprocessorsand data ow machines. Sisal programs are made up of separately compiledmodules, which comprise one or more function de�nitions. Functions have noside-e�ects; computation is by application of functions to values in expressions,which may return multiple values.Basic data types are boolean, integer, real and double real, complex and doublecomplex, null and character. Values may be structured using array, stream,record and union types. Arrays in Sisal are highly exible: powerful operationsare provided for de�ning array values; arbitrary subarrays can be selected andupdated; array bounds are determined by the expression which produces thearray value. Streams, which are potentially in�nite sequences with non-strictsemantics, provide pipelined parallelism. Parallel and sequential loops canbe expressed. A parallel loop allows generation of a range of values, withinstances of a loop body potentially executing in parallel for each value in therange. A variety of reduction and masking operators are provided to extractvalues from loop iterations. The sequential loop form expresses loops withdata dependencies between iterations. Higher-order functional programming ispossible in Sisal; function values can be de�ned and used. Typesets providea limited form of polymorphism by allowing an identi�er to take on any of aspeci�ed set of types; it is intended that typesets will allow useful polymorphismbut avoid the necessity for a complete type inference system.Figure 2 illustrates some aspects of Sisal 2.0. The function main is a functionof no arguments returning two results, each of type integer. These results arede�ned by a let construct, the Sisal mechanism for introducing local identi�ers.Because the language is single-assignment, a name may be bound to a valueonce only in a given scope (once per iteration in a loop body); the bindingcannot then be changed. In the let construct, i is bound to 1, and two resultsare de�ned. The �rst result is the value of the while expression. The whilealso introduces a new scope, binding new identi�ers i, j and k throughout theexpression. The second result of the let will be 1, re ecting the value of i inthe outer scope. We now focus on the while expression. The loop introducesidenti�ers i and j as carried values, that is, names which are rede�ned duringeach iteration (the point at which this rede�nition takes place is determinedby reading the de�nitions in the loop body sequentially). In this example, i isrede�ned as local to the loop, but is initialized from the value of i (viz, 1) inthe outer scope. The name k is local to the loop; here, it is used to capture the

234 Tools and Environmentsprogram p51% example from p51 of the reference manualfunction main (returns integer, integer)leti := 1 ;inwhile i < 5 do k := i ;i := i + 2 ;j := k + i ;returns product(i + j)end while, iend letend functionend program Figure 2 A Sisal program.value of i before it is rede�ned (in Sisal 1.2, this was referred to as old i). Theresult returned is formed by a product reduction; each time new values of thecarried values are formed, they are added together (i+ j); the loop as a wholede�nes a sequence of such values, which are then multiplied together to givethe result of the reduction. Hence, the value returned here is 91, the productof (1 + 2) + (1 + (1 + 2)) and (3 + 2) + (3 + (3 + 2)).The loop shown here is essentially sequential (although some �ne-grained par-allelism can be extracted on, for example, a data ow machine, by compilingthe rebinding of each carried value separately), as there are data dependenciesbetween successive iterations. When no such dependencies exist, we have aparallel loop, for which each loop body can be executed simultaneously (ex-pressions are side-e�ect-free), allowing generation of highly parallel code.4 STRUCTURE OF THE SEMANTICSThe dynamic semantic speci�cation is written upon the abstract syntax wede�ned for the Sisal language (see Section 4.1). It assumes that the Sisal pro-gram is correctly typed (integration of a type-checker in the Sisal environment

Formal Semantics and Environment for Sisal 235is planned). On the other hand, our speci�cation dynamically reports on errorswhich are not statically detectable, such as when a function designated as thestarting point for execution does not appear in the program.Execution of a Sisal program results in a tuple of values, even if that tupleonly contains one value. Sisal values can be constants, arrays, streams, unionsand function values (modeled as closures). Computing the result of a Sisal pro-gram requires to know which value is associated with each identi�er (e�ectiveparameters, carried names in loops, etc). All mappings between names andvalues are gathered in an environment. We describe its structure and requiredmanipulation primitives in Section 4.2.The semantics we have de�ned so far does not cover all the features of the Sisallanguage. Not yet speci�ed constructs are modularity and interfaces for foreignlanguages, typesets, and error management. However, we believe that majorfeatures of Sisal have been de�ned, including the single assignment principle,the absence of side-e�ects, higher-order functions, array and stream facilitiesfor parallelism. We are con�dent in the fact that specifying missing featureswill be rather straightforward, thanks to the way the semantic de�nition isstructured and the step by step re�nement of its design and development.4.1 An Abstract Syntax for SisalInstead of giving, in extenso, the whole abstract syntax of the Sisal language(109 sorts, 172 operators), we prefer to show speci�c constructs of the language.An executable Sisal system is a sequence of compilation units, including a pro-gram, interfaces and modules. A program is composed from a name and alist of declarations. A declaration can be either a type de�nition, a functionSYSTEM ::= compilation unit list;compilation unit list -> COMPILATION UNIT + ... ;COMPILATION UNIT ::= interface module program ;program -> NAME DECLARATION LIST ;DECLARATION LIST ::= declaration list ;declaration list -> DECLARATION * ... ;DECLARATION ::= import decl TYPE DEF FUNCTION DEF;Figure 3 An abstract syntax for Sisal - Program Part.

236 Tools and Environmentsde�nition or entities imported from other modules. The corresponding ab-stract syntax is de�ned in Figure 3. Note that upper-case identi�ers denotesorts, lower-case identi�ers denote operators. In an operator de�nition (`->'),we describe the number (the arity) and sorts of its descendents. Operatorscan be �xed arity operators (e.g. program has two descendents), list opera-tors (e.g. declaration list can have 0 or more descendents of the uniquesort DECLARATION) or atomic operators (carrying a syntactical value). A sortde�nition, (denoted with `::='), introduces a set of operators which are validdescendents for a given parent operator (e.g. import decl is one possible mem-ber of a list of declarations).The main feature in Sisal is expressions. This is shown in the abstract syntaxde�nition with the EXPRESSION sort which contains 40 operators, structuredin 4 subsorts (BINARY, PRIMARY, UNARY, CONSTANT) for clarity. Theseoperators include binary expressions, references to and generation of compoundobjects, as well as the let construct, selection and loop expressions.EXPRESSION ::= BINARY PRIMARY;BINARY ::= binary ;binary -> EXPRESSION REL OP EXPRESSION ;PRIMARY ::= UNARY name imported name CONSTANT invocationunion ref record ref union gen record genstream ref stream gen array ref array genarray update let conditional case for ...;UNARY ::= unary ;unary -> REL OP EXPRESSION ;Figure 4 An abstract syntax for Sisal - Expression Part.4.2 Semantic Values and EnvironmentValues in Sisal are either constants (boolean, integer, real, complex, double,character, string, errors), or arrays, union, records, streams, or closures, whichare pairs of �-expression (representing the function body) and environment.Environments are necessary to manage the binding between identi�ers andvalues since the value of an expression depends on the values of identi�ers thatoccur free in it, including bindings for function names, when they are declared

Formal Semantics and Environment for Sisal 237ENV ::= env;env -> PAIR * ... ;PAIR ::= pair ;pair -> NAME VALUE ;VALUE ::= CONSTANT closure array stream union record ;closure -> LAMBDA ENV ;LAMBDA ::= function def ;--- function def is defined in the abstract syntax as:--- function def -> FUNCTION HEADER EXPRESSION LIST ;array -> DIM DIM CONTENT ;dim content -> BOUNDARIES ARRAY ELTS ;boundaries -> LOWER UPPER ;stream -> STREAM ELT * ... ;STREAM ELT ::= VALUE TRIPLET;Figure 5 An abstract syntax for Sisal - Environment Part.via an assignment in a let or a for construct. We de�ne an environment as a listof pairs composed from a name and a value. Note that this structure is de�nedas part of the Sisal abstract syntax, uses Sisal operators (name, function def),as well as new operators (pair, closure, array, stream). Of course, thesede�nitions do not alter the concrete syntax of the Sisal language.We need to de�ne primitives for environment manipulation. Basically, we need(1) to add a new pair composed with a name and a (single) value and (2) tosearch for a name in the environment and get its associated value.Sisal respects the principle of single assignment. This means that there isno way of changing, in the environment, the value associated to a given name.Moreover, the environment has to re ect inheritance of surrounding scopes, andhiding rules when a rede�nition occurs. Primitives for environment manipula-tion are gathered in the environment program. Because Sisal allows multipleassignments, we need to de�ne the assignments set dealing with multiple dec-larations and values. The semantics is very simple: just collect the resultingpairs composed from each pair of declaration and value.

238 Tools and EnvironmentsOn the other hand, the set value in env de�nes rules to associate, in a givenenvironment, a value to a given name. The search is done in a left to rightmanner to respect scope rules.4.3 A synopsis of the semanticsWith the Typol formalism, it is possible to structure the semantic de�nitionin separate modules, each of which deals with similar concerns. Therefore,we have a variety of Typol modules specifying the dynamic semantics of allconstructs of the Sisal language, including values and environments (see Figure6 for a summary).The starting point of the semantics is to evaluate the main function body givenits name and its arguments (set root function). This set merely calls two othersets in order to �nd the function de�nition in the current program and to exe-cute it (see Section 5.1). This set is included in the program function executionwhich also contains a set to associate formal and actual parameters.The core of the language (expressions) is treated in the expression programwhich contains sets (for a list of expressions, identi�ers, constants, evaluationof operations on scalar types) and calls to other speci�c modules for evaluationof function invocation, selection, arrays, streams operators, for or let constructs(see Sections 5.2 to 5.6) Primitives for manipulation of the environment aregathered in a speci�c module environment (described in Section 4.2)Finally, scoping rules for functions state that when a given function name is notde�ned in the current scope, then it must be de�ned as a stand-alone unit in theprogram; to handle this case, in most sets we need to include the entire systemas a parameter to the rules. It can then be transmitted, as a subject, to othersets, providing access (throughout the program) to the outer-level environment.These sets are gathered in the system de�nition program.5 SEMANTIC DEFINITIONIn this section, we present the principles of the semantic de�nition, give intuitivemeanings of the main modules, and on several occasions, we precisely givejudgements, rules and axioms.

Formal Semantics and Environment for Sisal 239Module function execution:root function: function id, values ` system : valuesThe semantics of a system requires the evaluation of the main function.function execution: system, env ` expression list : valuesExecution of a body of a function, given a current scope.Module expressions:eval expression: system, env ` expression : valuesEvaluation of an expression.declarations: system, env ` decl def list : envUpdate the environment with new pairs.function invocation: system, env ` expression : valuesApplication evaluation.Module loops:eval for: system, env ` expression : valuesEvaluation of the for construct.initial return values: system, env ` return list : valuesComputes initial result values.iterate body: system, env, values ` test, for body, return list : valuesOne iteration step for the loop, depending on the tests.Module arrays:array gen: system, env ` expression : valuesArray generation.array ref: system, env ` expression : valuesArray reference.array update: system, env ` expression : valuesArray update.Module streams:stream gen: system, env ` expression : valuesStream generation.stream ref: system, env ` expression : valuesStream reference.Module system de�nition:function de�nition: name ` system : boolean, function defFunction de�nition of a function name in the systemtype de�nition: name ` system : boolean, type defType de�nition of a type name in the system||||||||||||Module environment:assignments: ` decl id list, values : envBuild new pairs from declarationsvalue in env: name ` env : valueSearch the value of a given name in the environment.Figure 6 Overall structure of the semantic de�nition.

240 Tools and Environments5.1 Function ExecutionThe root function set of the function execution program is the entry point intothe semantic de�nition with the two rules below (and their judgement):set root_function isjudgement FUNCTION_ID, VALUES |- SYSTEM : VALUES ;function_definition(FNAME |- SYSTEM : true(),function_def(function_header(_,FOR_PARAMS,_), EXPS)) &bind_parameters(FOR_PARAMS, EFF_PARAMS -> BIND_PARAMS) &function_execution(SYSTEM, BIND_PARAMS|- EXPS: VALUES)------------------------------------FNAME, EFF_PARAMS |- SYSTEM : VALUES;function_definition(FNAME |- SYSTEM : false(), _)--------------------------------------FNAME, EFF_PARAMS |- SYSTEM : values[];do error(FNAME, "not present in the program");end root_function;Given a name and actual parameters, the result of the semantics is a list ofvalues, provided the fact that the function is actually de�ned in the currentprogram. The binding between formal and actual parameters is accomplishedin the bind parameters set. Note that the environment in which the function isexecuted is reduced to this binding.The set function execution merely initiates the evaluation of a list of expressionscomposing the function's body. Function invocation is described in Section 5.3.set function_execution isjudgement SYSTEM, ENV |- EXPRESSION_LIST : VALUES;eval_expression_list(SYSTEM, ENV|- EXP_LIST -> VALUES)---------------------------------------SYSTEM, ENV |- EXP_LIST : VALUES;end function_execution;

Formal Semantics and Environment for Sisal 2415.2 Simple expressions and name scopingThis part of the language is, of course, the kernel of the language. Namescoping is done with the let and the for constructs. Expressions contain functioninvocation (Section 5.3), facilities for arrays (Section 5.5) and streams (Section5.6). We do not give the semantics of usual expressions such as identi�ers,constants, conditionals, etc, since they are not speci�c to Sisal and have beende�ned on several occasions.The Sisal language respects the principle of no aliasing which means that asingle name is associated with each value. Also, a value name is associatedwith a single value throughout its existence (principle of single assignment).These two principles have a signi�cant in uence on the management of theenvironment, especially for the semantics of assignments appearing in let or for(only these operators can alter the environment). Moreover, the fact that Sisalis a pure functional language (without side-e�ects) can be seen in the semanticde�nition with the form of the judgements dealing with expressions: the onlyresult is of the VALUES type (even for one single value), which means theenvironment remains unchanged after the evaluation of an expression.Name scoping is done with the let construct. The semantics is, as usual, tobuild a new environment using declarations and evaluate a list of expressionsinto a list of values within the resulting environment.However, the semantics of the declarations follow the so-called de�nition beforeuse rule. In other words, an expression de�ning a name can refer to values ofnames previously de�ned and mutually recursive declarations are not allowed.Moreover, each value name can be declared only once.set eval_let isjudgement SYSTEM, ENV |- EXPRESSION -> VALUES;declarations(SYSTEM, ENV |- DECL_DEFS : ENV1) &eval_expression_list(SYSTEM, ENV1|- EXP_LIST -> VALUES)--------------------------------------------------SYSTEM, ENV|- let(DECL_DEFS, EXP_LIST) -> VALUES;end eval_let;Lists of expressions are part of Sisal (for example, in a let construct, a list ofe�ective parameters, and multi-valued functions). Therefore, a set for evalua-tion of a list of expressions is required to evaluate each single expression andcollect the results.

242 Tools and EnvironmentsThe declarations set introduces new names in the environment, within an em-bedded scope, together with their associated values computed within this scope.The speci�cation re ects the left-to-right traversal of the declarations:set declarations isjudgement SYSTEM, ENV |- DECL_DEF_LIST : ENV;judgement SYSTEM, ENV |- DECL_DEF -> ENV;_, ENV |- decl_def_list[] : ENV ;SYSTEM, ENV |- DECL_DEF -> ENV1 &SYSTEM, ENV1 |- DECL_DEFS : ENV2----------------------------------SYSTEM, ENV|- decl_def_list[DECL_DEF.DECL_DEFS] : ENV2 ;collect_decl_ids(DECL_LIST -> DECL_IDS) &eval_except_lambda(SYSTEM, ENV, DECL_IDS |- EXP_LIST: VALUES) &assignments(|- DECL_IDS, VALUES: ENV1) &appendtree(ENV1, ENV -> ENV2)----------------------------------SYSTEM, ENV |- decl_def(DECL_LIST, EXP_LIST) -> ENV2;end declarations;Finally, the eval except lambda set treats lists of expressions: depending on thedeclaration (name or function header), the corresponding expressions will beevaluated or not. In the case of a function header, the associated expressionswill serve to build a closure for the function, within the current environment.Note that due to multiple assignments and multi-valued expressions, there isno one-to-one syntactical correspondence between names and expressions: asingle expression can be associated with more than one value name. Assumingtype-checking is correct, we can collect all names coming from declarations(calling the set collect decl ids) and be sure that a similar number of values willcorrespond. The set assignments builds the bindings from names and values.5.3 Function invocationIn Sisal, invoking a function relies on speci�c scoping rules: the function has tobe de�ned in the current environment, depending on the function name only. If

Formal Semantics and Environment for Sisal 243no applicable function occurs in the current scope, then the function de�nitionhas to appear in the program itself.Moreover, the function body will be evaluated in di�erent environments de-pending on where the function has been de�ned. If the function has beende�ned in the current scope, the new environment in which the function bodywill be evaluated comprises formal parameters (and their values) and inheritsall surrounding scope (allowing for hiding and overloading rules concerning re-de�nitions). On the other hand, if the function is de�ned as a stand-alone unit,the environment is reduced to the formal parameters (and their values). Allthis is expressed in the following function invocation set. Note that this speci-�cation allows higher-order functions: functions can be passed to and returnedfrom functions and be the values of expressions.set function_invocation isjudgement SYSTEM, ENV |- EXPRESSION : VALUES;eval_expression(SYSTEM, ENV |- EXP :values[closure(function_def(function_header(_,FOR_PARAMS,_),FUNC_BODY),ENV1)]) &eval_expression_list(SYSTEM, ENV |- EXP_LIST -> VALUES) &bind_parameters(FOR_PARAMS , VALUES -> BIND_PARAMS) &appendtree(BIND_PARAMS, ENV1 -> ENV2) &eval_expression_list(SYSTEM, ENV2 |- FUNC_BODY -> VALUES')--------------------SYSTEM, ENV |- invocation(EXP, EXP_LIST): VALUES';function_definition(NAME |- SYSTEM : true(),function_def(function_header(NAME,FOR_PARAMS,_), FUNC_BODY))&eval_expression_list(SYSTEM, ENV|- EXP_LIST -> VALUES) &bind_parameters(FOR_PARAMS, VALUES -> BIND_PARAMS) &function_execution(SYSTEM, BIND_PARAMS|- FUNC_BODY: VALUES')----------------SYSTEM, ENV |- invocation(NAME, EXP_LIST): VALUES';end function_invocation ;5.4 LoopsIn this section, we give the formal semantics of the for construct. In Sisal,loops can be controlled either using a distributive manner or using an iterative

244 Tools and Environmentsmanner, or using both. We just give here the semantics of loops with iterativecontrol.A loop in Sisal has a declaration part (which introduces carried values), a bodypart (which re-establishes carried values for the next iteration) and a returnpart (which packages the carried values into return values). A body part cancontain either a pre-test or a post-test which provide a termination condition.All this is simply expressed in the for set as follows:set eval_for isjudgement SYSTEM, ENV |- EXPRESSION -> VALUES;initial_return_values(|-RETURN_LIST -> RETURN_VALUES) &declarations(SYSTEM, ENV |- DDL : ENV1) &iterate_body(SYSTEM, ENV1, RETURN_VALUES |-PRE_TEST, FOR_BODY, RETURN_LIST -> _, VALUES)--------------------------------------------------------SYSTEM, ENV|- for(for_top(dot_in_list[], DDL, PRE_TEST),FOR_BODY, RETURN_LIST) -> VALUES;end eval_for ;The initial return values set computes a list of initial values for return values(return values), depending on the packaging construct (last value, reduc-tion, stream or array).The declaration part uses declarations to bind initial values of the carried valuesinto a new environment env1. Then, iterations are done until the terminationconditions are met (pretest, posttest). This is expressed as a recursionon the set iterate body in the semantic de�nition. Each iteration includes thecomputation of new values for carried values in a new environment (the callto declarations), and the computation of new return values (the call to iter-ate return). Finally, after the last iteration, return values are packaged and areconsidered as the semantic value of the for expression (the call to eval return).We just give here the Typol recursive rule which treats the continuation case(when both tests evaluate to true). Similar rules deal with the terminationcases (depending on which test evaluates to false, declarations are treated ornot). In these termination rules, a call to the set eval return handles the actualcomputation of the packaged result.

Formal Semantics and Environment for Sisal 245eval_test(SYSTEM, ENV |- PRETEST -> true()) &declarations(SYSTEM, ENV |- DDL : ENV1) &eval_test(SYSTEM, ENV1 |- POSTTEST -> true()) &iterate_return(SYSTEM, ENV1, RET|- RETURN_LIST -> RET') &iterate_body(SYSTEM, ENV1, RET'|-PRETEST, for_body(DDL, TEST), RETURN_LIST-> ENV2, VALUES)---------------------------------------------SYSTEM, ENV, RET |- PRETEST, for_body(DDL,POSTTEST),RETURN_LIST -> ENV2, VALUES;The eval test set merely calls the eval expression; when the test expression isa while, it directly returns the result, otherwise (with an until), it returns itsnegation. If, when one of the tests is missing, the default abstract syntax treeis no expression which always evaluates to true.The iterate return set, during each step of the iteration, computes new re-turn values, depending on the return expression list and the masking �lters.Then, when iterations stop, the eval return set actually computes the returnvalues, from previous return values (transmitted as parameters in the rule).For instance, when the return part includes a reduction invocation, such asproduct(i+j) in Figure 2, initial return values returns an empty sequence whileiterate return adds new values to the sequence, then eval return actually com-putes the reduction on the whole sequence of values produced by the loop.5.5 ArraysArray values have an abstract syntax which allows single or multidimensionalvalues (see Section 4.2). There are facilities for array generation, reference to,and update of, subarrays, and prede�ned operations such as size, concatenation,element-wise arithmetic operators, and so on.The formal semantics of arrays is the result of common research with Gaudiotand Chen from USC (the formal de�nition expressed in Typol is reported in[13]). We discuss in detail one important aspect of arrays: their generation.From an array generation expression like:

246 Tools and EnvironmentsA := array real [2..3, ..8:[2,7] 1.0; [2,8] 2.0;[3,..] 3.0;[otherwise] 0.0];an array value construction is speci�ed; here, a 2x8 array A is speci�ed, inwhich A27 is 1.0, A28 is 2.0, each value in row 3 is 3.0, and all other values arezero.In summary, the semantics of array generation can be written as follows:dimension(SYSTEM, ENV |- SIZE_DESCRS : DIM, BOUNDARIES_LIST) &build_array(SYSTEM,ENV,TYPE_SPEC,DIM,BOUNDARIES_LIST|- ARRAY_PARTS: DEF_ARRAY) &fill_array(SYSTEM, ENV, DEF_ARRAY |- ARRAY_PARTS : ARRAY)-------------------SYSTEM, ENV |- array_gen(TYPE_SPEC, SIZE_DESCRS,ARRAY_PARTS) : values[ARRAY];First, we specify the dimension and the boundaries from the size descriptionlist (2..3, ..8 in the example) in the set dimension. Then, we build the arrayitself with the set build array, speci�ed as :judgement SYSTEM, ENV, TYPE_SPEC, DIM, BOUNDARIES_LIST|- ARRAY_PART_LIST: VALUE;otherwise(SYSTEM, ENV, TYPE_SPEC |- ARRAY_PART_LIST : VALUE) &build(SYSTEM, ENV, DIM, BOUNDARIES_LIST, VALUE|-ARRAY_PART_LIST: DEF_ARRAY)-----------------------------------------------------------SYSTEM, ENV, TYPE_SPEC, DIM, BOUNDARIES_LIST|- ARRAY_PART_LIST: DEF_ARRAY;The �rst premise (otherwise) returns a default value which is speci�ed in theotherwise placement. Then, we actually build the array structure (def array)with the default value. At this point, the whole array value is built withdimension, lower and upper boundaries, and all the elements set with a defaultvalue.

Formal Semantics and Environment for Sisal 247Finally, the set �ll array examines each array part in sequence: from the place-ment son (subtree in the abstract syntax tree) a list of indices is generated,from the expression list son the evaluation process generates one or more val-ues. Then the set update, called with these indices and values, returns the �nalarray (space prohibits inclusion of details of these sets).Note that, in the absence of a size descriptor (optional in one-dimensionalarray), the set dimension returns a dimension and a lower bound defaultingto one and a free variable for the upper bound which will automatically beinstantiated by uni�cation in the module build.5.6 StreamsStreams in Sisal 2.0 are, like arrays, collections of homogeneous values. Theyare intended to be evaluated non-strictly in order to permit the use of poten-tially in�nite streams and to permit pipelined parallelism and input/outputoperations. Streams can be generated by both parallel and sequential loops,and by stream generators, which provide a high-level descriptive notation forstream values. Stream values can be consumed iteratively, or by using index-ing to access individual stream components or substreams. All accesses areregarded as abbreviations for sequences of �rst and rest operations (speci�edbelow).While our semantics is globally strict (call-by-value semantics), we de�ne anon-strict semantics for streams which permits us to deal with in�nite streamsand demand-driven output. The streams remain fully unevaluated, as wellas the expressions which use the stream values. One source of evaluation isa reduction operation applied to a stream; in this case, the stream is fullyevaluated. A second source occurs at the top-level when one result of the mainfunction is of type stream: the �nal result is computed in a demand-driven waywhich allows production of the stream to be regulated by its consumer. Theprinciple is, from an expression including streams, we generate one expressionwith the streams replaced with their �rst element, and another expression withthe streams replaced with their rest. Then, the �rst expression is evaluated inorder to get one value (e.g. to send to the output), and the second expressionremains as a result to be evaluated again.Streams are de�ned as lists of triplets or expressions. The former are theonly syntactical element source of potentially in�nite streams, and are keptin the stream value as they are. The latter are evaluated. For example, the

248 Tools and Environmentsdeclaration: S := stream integer [7, 9..15..2, 3*7]yields the value stream[7, triplet(9,15,2),21], and the substream selection S[2..]yields stream[triplet(9,15,2),21].As an illustration, we specify the substream selection operations �rst and rest(S[1], S[2..] in Sisal):set first isjudgement |- VALUE : VALUE ;|- stream[VALUE.ELTS] : VALUE ;|- stream[triplet(LOWER,_,_).ELTS] : LOWER ;end first;set rest isjudgement |- VALUE : VALUE ;|- stream[VALUE.ELTS] : ELTS ;no_next(LOWER, UPPER, STRIDE)----------------------------|- stream[triplet(LOWER, UPPER, STRIDE).ELTS] : ELTS ;next(LOWER, STRIDE -> LOWER')-----------------------------|- stream[triplet(LOWER, UPPER, STRIDE).ELTS] :stream[triplet(LOWER', UPPER, STRIDE).ELTS] ;end rest;6 AN INTERACTIVE ENVIRONMENTFOR SISALThis section is devoted to the �rst execution environment for Sisal 2.0. Thisenvironment has been generated, using Centaur v1.2 [17], from the syntacticand semantic speci�cations we have presented above. This environment can beused by two kinds of users:

Formal Semantics and Environment for Sisal 249novice Sisal programmers will build basic Sisal programs (with a simpli-�ed editing process, without actually knowing the syntax of the language,see Section 6.1) and compute their result with some animation tools fordebugging (see Section 6.2);Sisal experts will develop more advanced programs and will use the Typoldebugger to visualize various aspects of program interpretation, such aswhich inference rule currently apply, and their parameters, etc (see Section6.3). Thus, they will be able to check the validity of our semantic de�nition,and its consistency with the reference manual.6.1 The structure editorThe Sisal programming environment includes a parser and a pretty-printerwhich compose a syntactic editor. This syntactic editor provides a guidedediting mode [15] as well as an in-line textual editing mode (see Figure 7).Figure 7 The structure editor.

250 Tools and EnvironmentsThe window in the middle (\p51.sisal") shows, after parsing, the abstract syn-tax tree of an example program on p51 of the Sisal reference Manual [3]. Thisabstract syntax tree is presented in a concrete syntax form, using speci�c fontsand colors for keywords and comments. The abstract syntax is used to checkthe validity of editing operations. During the editing process, placeholders(meta-variables) can be easily introduced (using the \Ins Meta" button in the\editing" box on the left). For instance, the current selected (highlighted)meta-variable is an expression. This \hole" in the abstract syntax tree can be�lled up in two ways:type a complete expression on the keyboard; this is done freely (with text)and the whole expression will be parsed on request (using incrementalityfeatures of the generated parser) and the corresponding abstract syntaxsubtree will be hooked in the whole program.point with the mouse to abstract syntax operators (\Ctmenu" windowon the right-hand side) which can be inserted as an expression. Clickingon the for construct will replace the \expression" meta-variable with thefor pattern (using concrete syntax) and new meta-variables to be �lledup. Automatically, when another meta-variable is selected, the \Ctmenu"window is updated with the corresponding abstract syntax operators, andtheir concrete syntax. Here, the abstract syntax de�nition ensures thatthe whole abstract syntax tree for the program is syntactically correct.Finally, the editing window on the left provides help for navigation in the tree,changing the level of details, cut-and-paste operations, and so on.6.2 Execution of Sisal programsTo trigger the interpretation of a Sisal program, we provide a speci�c popupmenu containing one button \interpret". This button is a call to the dynamicsemantics of Sisal, namely the set \root function". The result of this executionis a list of values, which is displayed in another window. More precisely, clickingon \interpret" will transform the whole abstract syntax tree (in Lisp) into aProlog term which becomes the subject of the goal to prove using the semanticde�nition: "main", values[ ] |- SYSTEM : VALUESThen, the generated Prolog �les are automatically loaded and used for theproof. When the proof is completed, the \VALUES" variable contains the list

Formal Semantics and Environment for Sisal 251of result values. This term is, in turn, transformed into a Lisp abstract syntaxtree and displayed.During interpretation, some visual help is provided: the current expression tobe evaluated is highlighted. This mechanism includes iterations in loops, andcalls to functions de�ned in the current scope as well as functions declared asstand-alone units. This way the user is always aware of the execution schemeof the program.Figure 8 Execution of a Sisal program.Moreover, part of the semantic de�nition can be used directly (namely sets inthe \system de�nition" program) from the Sisal environment to provide theuser with information about identi�ers. For instance, the user can ask for thede�nition of a function identi�er. Then, the corresponding de�nition will behighlighted or an error message will occur when no de�nition is available. Webelieve that these tools considerably help the development of Sisal programs(see Figure 8 for an illustration).

252 Tools and Environments6.3 Visualizing Sisal semanticsThe Centaur system provides debugging tools for Typol speci�cations whichare very helpful when designing a new semantics or testing and evaluating anexisting semantics.These debugging tools are automatically invoked when the Typol speci�cationis compiled in the so-called debug mode. Triggering the interpret button in aSisal window then results in a new window, called \Semantics" window whichcontains the inference rule currently applied, as well as the name of the setit belongs to. Moreover, the subject of the current rule is highlighted in thesource program window so it is quite straightforward to follow the proof pro-cess (i.e. the progress of program interpretation). The current execution stateFigure 9 Visualizing Sisal semantics(associated to the current applied rule) is displayed on the left hand side of the\Semantics" window (try, proved, back or failed). According to this currentstate, one can force the transition to the next state (step, skip, fail, or retry).For instance the skip button is an attempt to prove the rule without displaying

Formal Semantics and Environment for Sisal 253the proofs of premises, and then stop in either the \proved" or \fail" state. Theother buttons on the left also act on the execution process (aborting, suspend-ing, continuing till the next break point). Finally, when a variable is selectedin the \Semantics" window, the \examine" button makes it possible to displayits value in another window, for instance, the current environment. When avariable is not yet instantiated, which is generally the case for result variableson the right hand side of sequents before the proof (\try" state), the message\Free Variable" is displayed in the \Examine" window. Thus, one can focus onthe semantics of the for construct, setting break points on the correspondinginference rules and then stepping to understand what happens, how carriedvalues are initialized, how the environment is updated during iterations, etc.We believe that these tools help the development of semantic de�nitions (seeFigure 9 for an illustration).7 CONCLUSIONS AND FUTURE WORKWe intend to complete the dynamic semantic de�nition, speci�cally modules,error management, and typesets. We also want to build more tools (visualiza-tion of execution, debugging, graphical representations, etc), again based onthe semantic de�nition, and expressed within the same formalism. Much of theSisal 2.0 de�nition is concerned with powerful array and sub-array descriptions.Issues such as general reduction operators and consequent non-determinism arealso raised. The work reported here lays the foundation for later analysis ofthese issues. Implementation issues are also important: can current high levelsof e�ectiveness of Sisal implementation on parallel machines be maintained inthe presence of (even limited) higher-order functionality, extensive overloadingand polymorphism? We hope to provide answers by extending this work todescribe the required optimizations and transformations to e�cient code.Thus, future work will include parallelizing tools for Sisal: we aim at specifyingthe IF1 [25, 11] and IF2 [27, 11] intermediate formats and semantics manip-ulations using Centaur and the Typol formalism. This includes the transla-tions from Sisal into the intermediate formats, the transformations themselves,and the proofs (possibly interactive and interfaced with other tools if need-ed). Thanks to formal speci�cations and proved transformations, we intendto lay out the base for the de�nition and programming of validated compilersfor Sisal. We also want to experiment in a signi�cant manner with programtransformations which are specialized to speci�c parallel architectures.

254 Tools and EnvironmentsWe want to build a complete environment for Sisal featuring the following:translation of Sisal programs into intermediate formats;textual or graphical representations of programs in intermediate formats;interactive transformations for parallel implementation of Sisal programs;representation and manipulation of the transformations themselves.This is part of a bigger project whose purpose is to formally de�ne the semanticsof two classes of concurrent languages and possible program transformations:functional and object-oriented languages. As presented in this paper, Sisal isused as an instance of the functional class, and we work with the languageEi�el// [6] as an object-oriented language ; the formal de�nition of Ei�el// isunder development [2]. While the two considered languages are very di�erenton the principles (functional and data- ow in the case of Sisal, object-oriented,imperative and asynchronous message passing for Ei�el//) they still presentsome important similarities (in, for example, wait-by-necessity as an implic-it data-driven synchronization mechanism [5], and signi�cant aspects of datadependency analysis). We hope to bene�t from cross-fertilization of the two do-mains, to be able to develop common intermediate formats and transformations,and thus common tools which will be integrated into a single environment.REFERENCES[1] Abelson, H, Sussman, G.J., Sussman, J. \Structure and Interpretation ofComputer Programs", MIT Press, 1985.[2] Attali I., Caromel D., Oudshoorn M. \A Formal De�nition of the DynamicSemantics of the Ei�el Language" Sixteenth Australian Computer ScienceConference (ACSC-16), Brisbane, Australia, 1993.[3] B�ohm A. P. W., Cann D.C., Feo J.T., Oldehoeft R.R., \Sisal ReferenceManual (language version 2.0)" Draft Report, 1992.[4] Borras P., Cl�ement D., Despeyroux T., Incerpi J., Kahn G., Lang B., Pas-cual V. \CENTAUR: the system" in Proc. of SIGSOFT'88, Third AnnualSymposium on Software Development Environments, Boston, 1988.

Formal Semantics and Environment for Sisal 255[5] Caromel D., \Concurrency and Reusability: From Sequential to Parallel"Journal of Object-Oriented Programming, (3) 3, September 1990.[6] Caromel D., \Towards a Method of Object-Oriented Concurrent Program-ming", Communications of the ACM, Vol. 36, Num. 9, September 1993.[7] Cl�ement D., Despeyroux J., Despeyroux T., Kahn G. \A simple applicativelanguage: Mini-ML" Symp. on Functional Programming Languages andComputer Architecture, 1986.[8] Despeyroux T. \Typol: a formalism to implement Natural Semantics" IN-RIA research report 94, 1988.[9] Dion B., Angeli L., Bravo Lastra A. \PARAGRAPH: an interactive en-vironment for parallelizing FORTRAN programs" INRIA research report1920, 1993.[10] Errington L. \Lassi Semantics", Sisal project internal report, Departmentof Computer Science, University of Adelaide, August 1991.[11] Feo, J.T., Cann, J.C. and Oldehoeft, R.R. \A Report on the SISAL Lan-guage Project", Journal of Parallel and Distributed Computing, December1990.[12] Fitzgerald, S. M. \Copy Elimination for True Multidimensional Arrays inSISAL 2.0", in Proc. of the Third SISAL Users and Developers Conference,San Diego, October 1993.[13] Gaudiot J. L., Chen Y. S. \Speci�cation of the Array Semantics for Sisal2.0" USC Computer Engineering Division Technical Report, TR CENG94-28, 1994.[14] Gentzen G. \Investigation into Logical Deduction", Thesis 1935, reprintedin \The collected papers of Gerhard Gentzen" E. Szabo, North-Holland,Amsterdam, 1969.[15] \Generation of Interactive Programming Environments II" Third ReviewReport, 1991[16] Gopinath K., \Copy Elimination in Single Assignment Languages", PhDThesis, Stanford University, 1989 (Technical Report CSL-TR-89-384).[17] Jacobs I., ed., \The Centaur 1.2 Manual", INRIA-Sophia-Antipolis, March1992.[18] Kahn G. \Natural Semantics" in Proc. of Symp on Theoretical Aspects ofComputer Science, Passau, Germany, LNCS 247, 1987.

256 Tools and Environments[19] Milner R., Tofte M., Harper R. \The De�nition of Standard ML", MITPress, 1990.[20] Pingali K., Beck M., Johnson R., Moudgill M., Stodghill P. \DependenceFlow Graphs: An Algebraic Approach to Program Dependencies" in Proc.of the 8th POPL, 1991.[21] Plotkin G.D. \A Structural Approach to Operational Semantics" ReportDAIMI FN-19, Computer Science Department, Aarhus University, Aarhus,Denmark, 1981.[22] Prasad S., Giacalone A., Mishra P. \Operational and Algebraic Semanticsof Facile: A Symmetric Integration of Concurrent and Functional Program-ming" in Proc. of 17th ICALP, LNCS 443, 1990.[23] Shirazi B., Chen H., Kavi K., Marquis J., Hurson A.R. \A Software De-velopment Tool for Parallel Program Scheduling and Assessment" in Proc.of International Parallel Processing Symposium, 1994.[24] Shirazi B., Chen H., Yeh J. S. \A visualization tool for display and in-terpretation of Sisal Programs" in Proc. of International Conference onParallel and Distributed Computing Systems, 1994.[25] Skedzielewski S., Glauert J. \IF1 - An intermediate form for applicativelanguages" Manual M-170, Lawrence Livermore National Laboratory, Liv-ermore, Calif., 1985.[26] Warren D.H.D., \Logic Programming and Compiler Writing", SoftwarePractice and Experience, Volume 10, Number 2, 1980.[27] Welcome M.L., Szymanski B.K., Yates R.K., Ranelletti J. E. \An applica-tive language intermediate form explicit memory management" ManualM-195, Lawrence Livermore National Laboratory, Livermore, Calif., 1986.[28] Wendelborn A. L., Garsden H. \Exploring the Stream Data Type in SISALand other Languages" in Proc. of the IFIP WG 10.3 Working Conferenceon Architectures and Compilation Techniques for Fine and Medium GrainParallelism, IFIP Transactions A-23, IFIP/North-Holland, 1993.