Trip report dsl 97
1 / 19

- PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '' - turi

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Trip report dsl 97

Trip Report: DSL ‘97

October 15-17, 1997

Santa Barbara CA

Aha natural history of dsls i
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!


  • DB systems:

    • schemas/forms/reports

  • Distributed Systems:

    • functionality/concurrency/communication/coherence/security


  • 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
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
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

More interesting presentations
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
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
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
Technical question:

  • what conventions does system impose on new primitives? This determines what level of interoperation is expected/required.

Don batory genvoca
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
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 load

method invocations

title, author, isbn

printable format

Minimizing network load

controlling slot copying






Emergent entities






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


  • aspect = modular unit of control over an emergent entity

  • talked at length about "AspectJ", but didn't mention Crista !?!

Domain transformations
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
Big Problems in AOP/DSL

  • understanding these transforms.

  • interfaces between different aspect languages (type checking, etc.)

Aha a foundation for aop
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
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