A Multi-stage Monadic Metalanguage Eugenio Moggi - - PowerPoint PPT Presentation

A Multi-stage Monadic Metalanguage

Eugenio Moggi

moggi@disi.unige.it

DISI, Univ. of Genova (joint work with S.Fagorzi)

FOSSACS’03 – p.1/8

Overview: Motivations

Why MSP (Multi-stage programming)? 1) Staging (Partial Evaluation) is an optimization technique usable in many areas: exploit info at early stages to generate customized code for later stages. 2) GC (Global Computing) applications operate with incomplete information about a dynamically changing environment, thus they need to interleave meta-programming activities (code generation, assembly of components) normal computational activities (IO, modification of local store,. . . ) security checks (at administrative domain boundaries) MSP supports interleaving of code generation and normal computation.

FOSSACS’03 – p.2/8

Overview: Aims

MMML (Multi-stage Monadic MetaLanguage) provides reference semantics describing the subtle interactions between staging (code generation) and computational effects. MMML adopts simple type system (fails to statically detect all run-time errors): no best option for a static type system [TD99,CMS??,Nan02,NT03], there are cases when dynamic error detection is preferable [FMP02].

FOSSACS’03 – p.2/8

Overview: Aims and Approach

MMML (Multi-stage Monadic MetaLanguage) provides reference semantics describing the subtle interactions between staging (code generation) and computational effects. MMML adopts simple type system (fails to statically detect all run-time errors): no best option for a static type system [TD99,CMS??,Nan02,NT03], there are cases when dynamic error detection is preferable [FMP02]. computational types Mτ: explicit distinction between values and computations code type τ (as in MetaML): reflective nature of languages for MSP annotated term constructors: operationally relevant information explicit in terms (as in multi-level languages for binding-time analysis) terms à la CRS (Combinatory Reduction Systems): for syntactic uniformity ChAM-like (Chemical Abstract Machine) approach: transparent simplification > (like ChAM heating) – PURITY programmable computation > (like ChAM reduction)

FOSSACS’03 – p.2/8

Technical Part on MMML Article stresses also that the addition of staging to pre-existing monadic metalanguage is MODULAR!

FOSSACS’03 – p.3/8

MMML: Syntax

τ ∈ T: : = X | Mτ | ref τ | τ1 → τ2 | τ type e ∈ E: : = x | l | c([xi]ei | i ∈ m) term, x ∈ X variable, l ∈ L location c ∈ C: : = ret | do | new | get | set | λ | @ | up | dn | cV | cM term constructor Syntax of terms à la CRS [Klo80] λ-abstraction λx.e becomes λ([x]e) application e1e2 becomes @(e1, e2) Haskell’s do notation do{x ← e1; e2} becomes do(e1, [x]e2) Alternative BNF for c ∈ C

• p ∈ Op: : = ret | do | new | get | set | λ | @ | up | dn ordinary term constructor

c ∈ C: : = opB annotated term constructor B ∈ {V, M}∗ Warning: in multi-level languages (e.g. in λM of [GJ95,Dav96]) cV and cM are identified, i.e. opB becomes opn where n is the length of the sequence B.

FOSSACS’03 – p.4/8

MMML: Naive Type System

τ ∈ T: : = X | Mτ | ref τ | τ1 → τ2 | τ type e ∈ E: : = x | l | c([xi]ei | i ∈ m) term, x ∈ X variable, l ∈ L location c ∈ C: : = ret | do | new | get | set | λ | @ | up | dn | cV | cM term constructor standard Γ ⊢Σ e: τ typing judgment, where Γ type assignment x: τ to variables x Γ ⊢Σ x: τ x: τ ∈ Γ

c

{Γ, xi: τ i ⊢Σ ei: τi | i ∈ m} Γ ⊢Σ c([xi]ei|i ∈ m): τ c: (τ i⇒τi|i ∈ m)⇒τ each term constructor c has a type schema (τ i⇒τi | i ∈ m)⇒τ

FOSSACS’03 – p.4/8

MMML: Type Schema for term constructors

τ ∈ T: : = X | Mτ | ref τ | τ1 → τ2 | τ type e ∈ E: : = x | l | c([xi]ei | i ∈ m) term, x ∈ X variable, l ∈ L location c ∈ C: : = ret | do | new | get | set | λ | @ | up | dn | cV | cM term constructor ret: τ⇒Mτ return value , do: Mτ1, (τ1⇒Mτ2)⇒Mτ2 sequential execution new: τ⇒M(ref τ) , get: ref τ⇒Mτ , set: ref τ, τ⇒M(ref τ) store operations λ: (τ1⇒τ2)⇒(τ1 → τ2) abstraction , @: (τ1 → τ2), τ1⇒τ2 application

up: τ⇒τ cross stage persistence , dn: τ⇒Mτ compilation

If c: (τ i⇒τi | i ∈ m)⇒τ, then cV : (τ i⇒τi | i ∈ m)⇒τ code value constructor cM: (τ i⇒Mτi | i ∈ m)⇒Mτ code generation where τi | i ∈ m stands for (τi | i ∈ m). For instance

λV : (τ1⇒τ2)⇒τ1 → τ2 code for abstraction λM: (τ1⇒Mτ2)⇒Mτ1 → τ2 generate code for abstraction

FOSSACS’03 – p.4/8

MMML: Type Schema for term constructors

τ ∈ T: : = X | Mτ | ref τ | τ1 → τ2 | τ type e ∈ E: : = x | l | c([xi]ei | i ∈ m) term, x ∈ X variable, l ∈ L location c ∈ C: : = ret | do | new | get | set | λ | @ | up | dn | cV | cM term constructor

up: τ⇒τ cross stage persistence (binary inclusion) dn: τ⇒Mτ compilation (may raise unresolved link error)

If λ: (τ1⇒τ2)⇒(τ1 → τ2), then

λV : (τ1⇒τ2)⇒τ1 → τ2 code for abstraction λM: (τ1⇒Mτ2)⇒Mτ1 → τ2 generate code for abstraction

FOSSACS’03 – p.4/8

Operational Semantics: ChAM-like approach

Id > Id′ simplification is β-reduction @(λ([x]e2), e1) > e2[x: = e1] Id > Id′ | done | err computation, where Id ≡ (X|µ, e, E) ∈ Conf program configuration (closed system) X ∈ Pfin(X) set of names generated so far µ ∈ S

∆

= L

fin

→ E current store e program fragment under consideration E ∈ EC: : = ✷ | do(E, e) | cM(v, [x]E, f) evaluation context for e where f: : = [x]e abstraction and v: : = [x]ret(e) value abstraction

FOSSACS’03 – p.5/8

Operational Semantics: Properties

Id > Id′ simplification is β-reduction @(λ([x]e2), e1) > e2[x: = e1] Id > Id′ | done | err computation, where Id ≡ (X|µ, e, E) ∈ Conf program configuration (closed system) CR > is confluent, and induced equivalence = is a congruence computation is preserved by further simplification, i.e. Id1 > D1 Id2 ∗ ∨ > D2 ∗ ∨ SR (Subject Reduction) Id well-formed and Id = = = ⇒ Id′ implies Id′ well-formed PR (Progress) Id well-formed implies Id = = = ⇒ , where = = = ⇒

∆

= > ∪ >

FOSSACS’03 – p.5/8

Operational Semantics: Computation Rules I

Id > Id′ simplification is β-reduction @(λ([x]e2), e1) > e2[x: = e1] Id > Id′ | done | err computation, where Id ≡ (X|µ, e, E) ∈ Conf program configuration (closed system) Administrative Steps A.0 (X|µ, ret(e), ✷) > done A.1 (X|µ, do(e1, [x]e2), E) > (X|µ, e1, E[do(✷, [x]e2)]) A.2 (X|µ, ret(e1), E[do(✷, [x]e2)]) > (X|µ, e2[x: = e1], E) Imperative Steps I.1 (X|µ, new(e), E) > (X|µ{l: e}, ret(l), E) where l ∈ dom(µ) I.2 (X|µ, get(l), E) > (X|µ, ret(e), E) provided e = µ(l) I.3 (X|µ, set(l, e), E) > (X|µ{l = e}, ret(l), E) provided l ∈ dom(µ)

FOSSACS’03 – p.5/8

Operational Semantics: Computation Rules II

Id > Id′ simplification is β-reduction @(λ([x]e2), e1) > e2[x: = e1] Id > Id′ | done | err computation, where Id ≡ (X|µ, e, E) ∈ Conf program configuration (closed system) Code Generation Steps (only unary case λM) G.1 (X|µ, λM([x]e), E) > (X, x|µ, e, E[λM([x]✷)]) rename x to avoid clashes with X G.2 (X|µ, ret(e), E[λM([x]✷)]) > (X|µ, ret(λV ([x]e)), E)

• ccurrences of x in e are re-captured

FOSSACS’03 – p.5/8

Operational Semantics: Computation Rules II

Id > Id′ simplification is β-reduction @(λ([x]e2), e1) > e2[x: = e1] Id > Id′ | done | err computation, where Id ≡ (X|µ, e, E) ∈ Conf program configuration (closed system) Compilation and Run-time Errors C.1 (X|µ, dn(vc), E) >

• (X|µ, ret(e), E)

if e = vc↓ err if vc↓ undefined where vc ∈ VC: : = x | up(e) | cV ([xi]vci|i ∈ m) code value and Demotion vc↓ maps code value vc: τ to represented term e: τ x↓ undefined up(e)↓= e (base case, like x) cV ([xi]vci|i ∈ m)↓= c([xi]ei|i ∈ m) provided ei = vci[xi: = up(xi)]↓ for i ∈ m

FOSSACS’03 – p.5/8

An important Lemma

If (X|µ, e, E) > (X′|µ′, e′, E′) and FV(µ, e) ∪ CV(E) ⊆ X and FV(E) ⊆ X − CV(E) then X ⊆ X′ , dom(µ) ⊆ dom(µ′) and FV(µ′, e′) ∪ CV(E′) ⊆ X′ and FV(E′) ⊆ X′ − CV(E′) where FV(_) set of free variables, CV(_) set of captured variables, e.g. FV(cM(v, [x]E, f))

∆

= FV(v, f) ∪ (FV(E) − x) CV(cM(v, [x]E, f))

∆

= x ⊎ CV(E)

FOSSACS’03 – p.6/8

An important Lemma

If (X|µ, e, E) > (X′|µ′, e′, E′) and FV(µ, e) ∪ CV(E) ⊆ X and FV(E) ⊆ X − CV(E) then X ⊆ X′ , dom(µ) ⊆ dom(µ′) and FV(µ′, e′) ∪ CV(E′) ⊆ X′ and FV(E′) ⊆ X′ − CV(E′) Well-formed Configuration ∆ ⊢Σ (X|µ, e, E)

∆

⇐ ⇒ dom(Σ) = dom(µ) and dom(∆) = X [∆ assigns code types to x ∈ X] and µ(l) = el and Σ(l) = τl imply ∆ ⊢Σ el: τl exists τ s.t. ∆ ⊢Σ e: Mτ exists τ ′ s.t. ∆, ✷: Mτ ⊢Σ E: Mτ ′ λM ∆, ✷: Mτ1 → τ2 ⊢Σ E: Mτ ′ ∆, x: τ1, ✷: Mτ2 ⊢Σ E[λM([x]✷)]: Mτ ′ by the lemma x should not occur in E.

FOSSACS’03 – p.6/8

Summary of Achievements

We have introduced a multi-stage monadic metalanguage MMML, main advantages SEPARATE simplification (no user control on simplification strategy) and computation (user control on order of evaluation) ALL operationally relevant information explicitly in terms smooth extension to multi-staging: NO CHANGE to simplification,

• nly ONE new clause for evaluation contexts,

and FEW additional computation rules BETTER handling of scope extrusion, by keeping a log of generated names

FOSSACS’03 – p.7/8

Further Work on Monadic Metalanguages

simplification: one may replace λ-calculus with other pure calculi computation: one may consider multi-lingual extensions, where a variety of programming languages (monads) coexist multiple monads, but only one code type constructor

• ne cM i for each monad, but
• nly one code value constructor cV

e: M 1M 2τ program in PL1 generating representation of program in PL2

FOSSACS’03 – p.8/8

Further Work on Compilation

May compilation become a simplification rule with refined typing? dn: [τ]⇒[τ] exploit close types [CMS??] dn: ✷(τ[∅])⇒τ similar idea using refined code types [Nan02] dn: (∀α.τα)⇒τ exploit encapsulation of representation [NT03] main difficulty: proof of SR for simplification. Alternative compilation rules, e.g. use lazy demotion (some clauses): upV n(e)↓= e retV n+1(e)↓= dnV n(e)

FOSSACS’03 – p.8/8

Further Work on Implementation Issues

The ChAM-like semantics for MMML is too abstract terms are considered modulo α-conversion simplification is β-reduction (instead of a deterministic strategy) substitution does automatic renaming of bound variables Implementations should be consistent with the reference semantics, but manipulate concrete terms use a naive substitution adopt a deterministic simplification strategy make explicit generation of fresh names (gensym)

FOSSACS’03 – p.8/8