CS 541 Lecture -*- Outline -*- * Denotational semantics of mini Cecil discuss the semantics of mini Cecil in class. ** overview *** algebras splitting semantics into 2 parts: 1. exprs and statements ("client" of algebra) compute on top of algebra 2. model of classes and methods called an algebra *** why? modularity of semantics ability to look at properties of one part without going into the other. study representation independence use MFPS talk ** denotational semantics coded in SML see Watt's section 4.4 for the general idea of semantic prototyping and an example without the module system involved. -------------------------- OVERVIEW OF MINI-CECIL SEMANTIC PROTOTYPE Build by typing to SML: use "make_prototype.sml"; Where to find the 3 parts of the denotational semantics: 1. Abstract Syntax AbstractSyntax.sml 2. Semantic Domains ClientSemanticFunctions.sml 3. Semantic Functions ClientSemanticFunctions.sml SemanticFunctions.sml Naming Conventions: Signatures ...Sig.sml Functors ...Fun.sml ------------------------------- ------------------------------- DEPENDENCIES IN THE SEMANTIC PROTOTYPE ListHelpers SetFun SetHelpers AbstractSyntax ^ ^ ... ^ | | | AlgebraSignatureFun FiniteFunctionFun ^ ^ | | ExternalsFun | AlgebraFun ^ | ^ | | | Environments MiniCecil ^ ^ ^ | | | ClientSemanticFunctions Visibles ^ ^ | | SemanticFunctions ^ | Test -------------------------- The stuff at the top is used in many places. Almost all of these have a signature too. The Client... stuff doesn't change the algebra at all Environments are polymorphic, sets are monomorphic when the functor is instantiated. The structure Visibles contains the built-in operations in the form of an algebra. The structure MiniCecil instantiates the ExternalsFun, AlgebraSignatureFun, and AlgebraFun passing along the parameters needed for Mini-Cecil. The functor ExternalsFun is a place to put stuff about externally visible observations; bool and int types, and has structures for for type names and sets of type names. ** environments look at EnvironmentSig.sml ** stores (see also Watt seeection 3.2.1) mention that this model is different slightly look at ClientAlgebraSig.sml ** reading the semantics (Watt section 4.1) *** semantic domains look at ClientSemanticFunctions.sml *** semantic functions **** expressions look at the signature of evalExpr, and explain it. say why Sigma is used (first) note that this code uses only the client part of algebras Q: can you explain to someone else every other clause? Q: How are variables modeled? Objects? Q: How are messages handled? Getting fields? Q: Can expressions have side effects? Q: What expressions have no side effects? **** statements (compare Watt 3.2.2) Q: can you explain to someone else every other clause? Q: What is going on in assignStmt? setFieldStmt? Q: So how does denotational semantics handle mutation and change? **** declarations see Watt section 3.3.2 Q: How does elaborate compare with elaborate in the operational semantics? Q: What would have to change if we allowed initialization of declarations? Q: How would that affect the signatures of the semantics functions? ** procedure definitions see Watt section 3.4 Q: What is elaborateProcedure doing? Q: Are these recursive? we'll study recursion later... Q: What's the procedure calling mechanism? Q: Looking at the semantics can you tell what a procedure means? Q: How does elaborateProcedure compare to elaborate? ** type, class, and method definitions Look at SemanticFunctions.sml (compare Watt section 3.5 for modeling of objects) *** type definitions add type to signature, and type of variables as well. variable types look like Var[T]. think of variables as a special kind of object. *** class definitions look at compileClass... assume that class names are the same as type names The creator method name is the same as the class name, not "new_..." as in the operational semantics. For each class name, add a type to the signature for the type of the values of objects of that type (called a sort). This is what ClassIdToSort'sName does. In the signature, there is a set of types called ObjectTypes, these are all represented by locations (they are objects), the class name is added to this set. The signature has a map from type names to sort names, TtoS; this mapping is extended Look at the signature of algebras, AlgebraSig.sml Q: how are methods represented? Q: What is the type of the alloc_this function inside compileClass? OPS' will be a function that extends the algebra's OPS function. Make up the new algebra with the new method. Q: How are getting and setting fields handled? look at AlgebraSig.sml *** method Formal Decls elaborateMethodFormalDecl is one place to consider making the change for call by constant... *** methods look at compileMethod Get the argument names, classes, and types Q: What is the type of this_method? What does it do? *** programs look at evalProgram Q: What is VISvariabletypes? SigmaVIS adds the VISvariabletypes to the signature. Then we compile the types, to produce Sigma, Then AlgebraVIS has its ObjectTypes and SORTS set from Sigma ObjectTypes is set to the types of all variables. Then the classes are compiled, giving a new signature and algebra, Then the methods are compiled, giving another new signature and algebra. Then the procedure declarations are elaborated, and finally the main is elaborated. Q: What is the type of evalProgram? How does it relate? ** reading a semantics see Watt's section 4.1 *** semantic domains look again at the semantic domains in ClientSemanticFunctionsSig.sml (and also in ClientAlgebraSig.sml) (If these are written as usual) these tell you a lot about the langauge. For example, Q: Are procedures first-class values? What would change otherwise? Q: Can procedures have side-effects? What would change otherwise? Q: Can the algebra change by means of a procedure call? Q: Can a procedure jump to another part of the program, or must it always return to its caller or fail? *** semantic functions look at the types of the semantic functions in ClientSemanticFunctionsSig.sml (If these are written as usual) these tell you a lot about the langauge. For example, Q: Can expressions have side effects? What would change otherwise? Q: Can an expression cause a jump? Q: Can an expression produce more than one value (nondeterminism)? Q: Can an expression change the environment? Q: What order are the arguments of a procedure call or message send evaluated in? Q: What would it say if we used stor instead of stor' in evalExprList? ---------------------------- DENOTATIONS FOR DIFF. KINDS OF LANGUAGES phrase class domain of denotations PURE FUNCTIONAL Expression Environ -> Value Declaration Environ -> Environ IMPERATIVE WITH NO SIDE EFFECTS IN EXPRS Expression Environ -> Store -> Value Command Envrion -> Store -> Store Declaration Environ -> Store -> Environ x Store IMPERATIVE WITH SIDE EFFECTS IN EXPRS Expression Environ -> Store -> Value x Store (rest same) ---------------------------- discuss the reasons for these differences Q: What category does mini-Cecil fall into? A similar classification can be made in terms of abstractions. See Watt's table 4.2 (p. 105)