Squeak, Newsqueak, Obliq PL Seminar 10/24/2007

Of mice and menus Cardelli and Pike ’85: Squeak: a language for communicating with mice Proof-of-concept embedded DSL for UI’s Compiles to C (single OS process) Semantics: pure, CSP, tail-recursive

Some combinators Send, receive: c!v, c?v Non-deterministic choice: p :: p Sequential composition: p. p Parallel composition: p & p Timeout: wait[e] p || p Escape to C: { C expression }

Pre-defined channels Mouse clicks: UP, DN Mouse cursor: M Enter/leave mouse region: E, L Keyboard input: K Absolute time: T

Example: display typing on clicks proc Mouse = DN?. M?p. moveTo!p. UP?. Mouse proc Kbd(s) = K?c. if c == NewLine then typed!s. Kbd(emptyString) else Kbd(append(s,c)) fi proc Text(p) = < moveTo?p. Text(p) :: typed?s. { drawString(s,p) }?. Text(p) > type = Mouse & Kbd(emptyString) & Text(nullPt)

Restrictions Fixed set of channels Fixed set of processes No real datatypes; all data manipulation in C

Check list Concurrency: yes Shared memory: no Parallelism: no Distributed computation: no

Journey to the C side Pike ’90: The implementation of Newsqueak Pike ’94: Newsqueak: a language for communicating with mice Intended for full GUI applications (in particular: window system) Semantics: CSP, higher-order(-ish), impure, no references!, tail-recursive

Semantics C-like types (safety? unclear) Dynamic creation of processes ( begin ), channels ( mk ) Ints, bools, chars, records, arrays First-class functions—no closures Mutable data but copying semantics!

Performance model Meticulously optimized driver loop Reference counting Copy-on-write Tail-recursive return ( become )

Closure conversion on spawn f := prog() { a:int; begin prog(){ a=1; }(); }

Closure conversion on spawn f := prog() { a:int; begin prog(a:int){ a=1; }(a); }

Check list Concurrency: yes Shared memory: no Parallelism: no Distributed computation: no

Obliq: distributed lexical scope Cardelli ’95: Obliq: a language with distributed scope Target applications: “Distributed scripting”— telecollaboration, telemarketing, navigation Semantics: local mutable objects but roaming closures, threads and locks

Distributed lexical scope Objects and variables are mutable Objects never migrate; passed by reference Migrated references become network references Cloning is possible; always explicit Closures can migrate, too Free variables become network references

Example: computation server (* Site A *) var q = proc() end; net_export("computeServer", Namer, { rexec => meth(self, p) q := p; p() end }); q; q(); (* Site B *) let cs = net_import("computeServer", Namer); var x = 3; cs.rexec(proc() x := x+1 end); x; is now 4 is now 5 is now proc() x := x+1 end

Agents Distributed programming idiom Migrate both state (“suitcase”) and computation (continuation) Receive local information (“briefing”) upon migrating to new site

Agents let rec agent = proc(suitcase, briefing) (* work at the current site *) (* decide where to go next *)... (* run agent at nextSite with suitcase *) hop(nextSite, agent, suitcase); end;

Agents let hop = proc(agentServer, agent, suitcase) agentServer( proc(briefing) fork(proc() agent(copy(suitcase), briefing); end); ok end); end;

Shared memory Mutable state is completely unprotected Keyword protected makes object externally uncloneable, immutable Keyword serialized makes object operations externally atomic Modula-3 mutexes, locks, conditions

Check list Concurrency: yes Shared memory: yes Parallelism: yes Distributed computation: yes

Summary Concurrent resources as channels Copying mutable data probably shouldn’t be implicit (that is so weird) By-reference semantics can extend to distributed setting as network references Not much insight here for dealing with shared memory