Com S 641 meeting -*- Outline -*- * the parameterization and correspondence principles (Schmidt 3) abstractions are more useful if they can be used in slightly different situations ** principles ------------------------------------------ PARAMETERIZATION AND CORRESPONDENCE PRINCIPLES (SCHMIDT 3) Parameterization: Phrases from any syntactic class should be Correspondence: Abstraction and parameterization mechanisms should Lambda abstraction: Allow prameterized phrases, i.e., lambda abstractions. ------------------------------------------ ... allowed as parameters. ... correspond semantically. That is, the semantics of define I2 = U in ... I2 ... should be the same as define I1(I2:theta) = ... I2 ... in I1(U) hence the semantics of free identifiers should be independent of the way they are bound. Q: Why is correspondence a good thing? Adding lambda abstractions is an orthogonal addition, shows that naming (abstraction) and parameterization are really orthogonal dimensions. ------------------------------------------ TYPE RULES FOR PARAMETERIZATION (3.10) Syntax (schematic): D ::= ... | define I1 (I2: theta1) = U U ::= ... | invoke I(V) V ::= ... | I Type attributes: theta ::= ... | Typing rules: ------------------------------------------ ... theta1 -> theta2 pi' |- U:theta2 _____________________________________________________ pi |- define I1(I2:theta1) = U:{I:theta1 -> theta2}dec where pi' = pi unionMinus {I2:theta1} where pi1 unionMinus pi2 = pi2 U (pi1 - {(i:v) | (I:w) in pi2 and (I:v) in pi1}) = pi2 U {(i:v) | (i:v) in pi1 and i not in dom(pi2)} i.e., pi1 with pi2 overriding any common definitions. (Note: U is standard union) ------------------------------------------ TYPE RULES FOR LAMBDA ABSTRACTION Syntax: D ::= ... | define I = A A ::= \I:theta . U U ::= ... | invoke I(V) V ::= I Typing rules: ------------------------------------------ the only interesting typing rule is the usual one for lambda. ... pi |- A : t1 -> t2 ___________________________________________ pi |- define I = A : {I:t1 -> t2}dec pi' |- U : t2 ____________________________________ pi |- \I:t1.U : t1 -> t2 where pi' = pi unionMinus {I:t1} pi |- I : t1 -> t2, pi |- V : t1 ___________________________ pi |- invoke I(V) : t2 pi |- I : t, if (I:t) in pi ------------------------------------------ PARAMETERIZATION SEMANTICS OVERVIEW kind of semantics parameter lazy eager expression location numeral command declaration type struct. function, procedure,... ------------------------------------------ Q: What do we mean by a lazy or eager semantics for parameters? ... by name by value ? (by name) by reference by const by const ? (normal) -- (backtracking point) ? (normal) -- ? (normal) -- ? (by name) -- one thing to note: our semantic axis is more systematic/general than the usual terminology In the terminology of Friedman, Wand, and Haynes, Schmidt's language uses the direct model (for records). Q: Why should function parameters be lazily evaluated? by the correspondence principle, should be same as fun I = E but then what does this say about expression parameters?