trip report dsl 97
Skip this Video
Download Presentation
Trip Report: DSL ‘97

Loading in 2 Seconds...

play fullscreen
1 / 19

Trip Report: DSL ‘97 - 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 ' Trip Report: DSL ‘97' - 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