Trip report dsl 97
Download
1 / 19

Trip Report: DSL ‘97 - PowerPoint PPT Presentation


  • 75 Views
  • 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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!


Examples
Examples:

  • DB systems:

    • schemas/forms/reports

  • Distributed Systems:

    • functionality/concurrency/communication/coherence/security


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

library

library

printer

book

user


Emergent entities

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


Aspects
Aspects

  • 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


ad