Transcript DSL-conf
Trip Report: DSL ‘97 October 15-17, 1997 Santa Barbara CA AHA! Natural History of DSLs (I) • In domain engineering, you analyze a set of applications for commonalities and dimensions of variation. Design a DSL to express each dimension of variation. Then weave the results together. • Are these aspects?? • NO! Examples: • DB systems: – schemas/forms/reports • Distributed Systems: – functionality/concurrency/communication/cohe rence/security Examples • Cache coherence protocols (Chandra, Larus, et al) • Web/voice response systems [Mawl] (Atkins, Ball, et al) – service logic/presentation • 3D animation (Elliott) – model/presentation Morals for us • in order to make progress, we need to have a domain (a family of applications) to analyze. • "C++ data structure programs" isn't specific enough. • Who can we collaborate with? • QoS a good start, but still maybe not specific enough. AHA! Natural History of DSLs (II) • DSLs start out as "pure embedded" DSLs, ie libraries embedded in GPLs. • Turning this into a standalone language restricts flexibility, BUT • Now can do better analysis of DSL programs • Can reason at domain level instead of hostlanguage level • Big theme of conference More Interesting Presentations • Zephr ASDL -- possibly useful tool – maybe a good customer, too • Khepera -- automatically adds debugging support to transformation systems • Use postprocessor to give user output in domain-specific terms (for errors, too) Simonyi -- Intentional Programming • programmer's intention is always in domain terms • abstraction object = programmer's intention • IP: a new habitat for high level abstractions • program is network of objects (intentions) • objects know how to display themselves (at lesser or greater level of detail (?)), how to compile themselves given info about context, etc. Simonyi -- Intentional Programming (II) • My summary: like visual programming: network of objects is primary, textual representation is secondary. Program by opening property sheets like Windows 95. • Gregor's summary: smalltalk/interlisp done "right" (ie with modern engineering). Technical question: • what conventions does system impose on new primitives? This determines what level of interoperation is expected/required. Don Batory -- Genvoca • type equations aren't functions; they are specification, like specification of a protocol stack. • not right to think of IO or OI evaluation: the system looks at the protocol stack and weaves it together. • He’s waiting for us to send him specs!! Kiczales -- Aspect-Oriented Programming • separation of concerns, modularity is good • but traditional design captures only part of system behavior • can't talk about "emergent entities" – path of a msg through a system – dataflows (lifetimes, source/sink of data item) – control states (concurrency, blocking relations, stack state) Minimizing network controlling slot copying library library load printer book user method invocations title, author, isbn printable format library Emergent entities library printer book user • emerge1 during program execution – from (possibly non-local) interactions of the components • are not components – do not exist explicitly in the component model or code 1 emerge: to become manifest; to rise from or as if from an enveloping fluid; come out into view Aspects • aspect = modular unit of control over an emergent entity • talked at length about "AspectJ", but didn't mention Crista !?! Domain Transformations • Reflection links static and dynamic domains • other linking transforms: unfolding, CPS, PE, ... • like Fourier transform: transforms from time domain to frequency domain-- what's local in one is distributed in the other. Big Problems in AOP/DSL • understanding these transforms. • interfaces between different aspect languages (type checking, etc.) AHA! A Foundation for AOP • Flows, etc are attempt to capture/describe dynamic behavior • Think about interpreter: – can easily capture info about variable binding/flow, etc. – so what's implicit in pgm text can be explicit in interpreter – pgm text is implicit in interpeter A Foundation for AOP (II) • So could easily imagine interpreter with annotations to collect certain dynamic info and act on it. • Semantics! • Turn into compiler by PE of some sort