Trip Report: DSL 97

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.
• Hes 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
controlling slot copying
printer
library
library
book
user
14
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