1. Trip Report: DSL ‘97 October 15-17, 1997 Santa Barbara CA

2. 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!

3. Examples: DB systems: –schemas/forms/reports Distributed Systems: –functionality/concurrency/communication/cohe rence/security

4. 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

5. 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.

6. 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 host- language level Big theme of conference

7. 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)

8. 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.

9. 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).

10. Technical question: what conventions does system impose on new primitives? This determines what level of interoperation is expected/required.

11. 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!!

12. 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)

13. Minimizing network load printer library user library title, author, isbn printable format controlling slot copying method invocations book

14. Emergent entities printer library user book library emerge 1 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

15. Aspects aspect = modular unit of control over an emergent entity talked at length about "AspectJ", but didn't mention Crista !?!

16. 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.

17. Big Problems in AOP/DSL understanding these transforms. interfaces between different aspect languages (type checking, etc.)

18. 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

19. 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