1 / 19

Trip Report: DSL ‘97

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.

turi
Download Presentation

Trip Report: DSL ‘97

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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/coherence/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. method invocations title, author, isbn printable format Minimizing network load controlling slot copying library library printer book user

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

  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

More Related