Prism criticism
Jim Little
jiml@inconnect.com
Mon, 07 Jun 1999 02:02:40 -0600
This is a multi-part message in MIME format.
--------------D917655DC7B0E17539051175
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Maneesh,
Sorry I wasn't able to answer your questions on IRC Saturday. As you
know, it was pretty hectic there, and I also having a very intense
conversation with Brian & Tril that was taking nearly all of my
attention. Hopefully this message will answer the questions you had...
Maneesh Yadav wrote:
> What makes [the Prism meta-metamodel] so special that it would be the choice for
> representation in textual and visual? There are other languages that
> assume just as much your yet are easier to write and have the adavtage of
> already being implemented over platforms, visual and textual environments
> (eg C++)? SO would you code the mini languages you speak of in prism or
> the applications or both? I don't see where this Prism syntax would be
> used?
I'm creating a new kind of compiler -- the Prism compiler -- which acts
as a "sandbox" where Prism-specific mini-languages and mini-compilers,
written by third parties, can interoperate. The Prism meta-metamodel,
or "Prism syntax," as you call it, is the internal format used by the
Prism compiler to represent programs. I need some standardized format
so the mini-languages and mini-compilers can interoperate.
I created the meta-metamodel because I didn't want to use plain text or
syntax parse trees as the compiler's internal format. Plain text is too
hard to manipulate programatically, and syntax parse trees are too
closely tied to context-free grammars. (But if you're interested in a
Prism-like system that uses syntax parse trees as the internal format,
check out Pliant. http://pliant.cams.ehess.fr/)
> Why not just use well tested and apparently more robust C or a given
> bytecode [for the meta-metamodel]?
C is too closely tied to the imperative, structured programming
paradigm. It would be hard to create a mini-language (metamodel) that
wasn't imperative if I used C. It's also plain-text, which is difficult
to manipulate programmatically, as I mentioned above. Bytecode has
similar problems.
> > >[Maneesh: Won't all these diffierent languages increase complexity, not reduce it?]
> >
> > This is a really good point, and something I'm a concerned about. My
> > hope is that each mini-language will be really small [and thus be easy to understand].
>
> Have you considered the fact then you would be trading off power?
It's true that each mini-language, by itself, will be very simple and
low-powered. That's intentional, because it means each mini-language
will be easy to learn. But since the mini-languages will interoperate
(hopefully), the power of Prism should be exponentially related to the
diversity of available mini-languages/compilers.
By the way, these mini-languages and mini-compilers which will be used
inside of the Prism compiler don't necessarily ship with Prism. They
are loaded at runtime. (The code to do this is already done.)
> I really don't see how can possibly test this hypothesis by making
> minilanguages that cover a wide enough spectrum in some reasonable amount
> of time by yourself, or if the effort would warrant a number of people
> doing it [...]
I plan to produce a fairly basic core set of mini-languages (actually,
"metamodels"). First on the list is interoperable data structures and a
simple structured imperative language, or if I quickly see the way, an
interoperable imperative language. Once that's done, I'll have a usable
system.
At that point, I can produce some complete examples and one "exotic"
metamodel, such as an FSM (finite state machine) model, that shows the
power of Prism. (Complex finite state machines are notoriously
difficult to code well in standard imperative languages.) At this
point, I'll announce Prism to the general open-source-programming public
on a site such as Slashdot. I'm fairly confident that I can attract at
least two or three other people interested in working with Prism at that
point.
As more people work with Prism and create new metamodels, the more
useful it will become, and, I assume, the more users it will attract.
It should snowball in fairly short order... assuming, of course, that I
can get to that first step where Prism is minimally usable. (That's the
trick, of course.)
> [...] and how it would be any different from the fact that there
> generally are tonnes of mini languagesfor various tasks already available
> (POV for raytracing, OpenGL for real time 3d, SQL for database, Java for
> dinky web applets), [...]
The difference is that the mini-languages would interoperate. Anybody
who's used a mini-language has experienced its curse:
1) It's not powerful enough. [e.g., Javascript] Or...
2) It's grown to be powerful enough, but now it's no longer a
mini-language, and that evolutionary growth has made it a morass of
difficult-to-understand features and weird syntax. [e.g., Perl]
With Prism, if one mini-language didn't have the powerful feature you
needed, you would find the one that did and add it to the mix. (Solving
curse #1.) Since each mini-language designer would be aware of this,
each mini-language would be designed to be interoperable rather than
full-featured, focusing on one specific type of problem. (Solving curse
#2.)
> [...] and it is already terribly apparaent to me that
> linking these things after designing them is not an easy task, just ask
> any one who uses Java and SQL or wants a modeller that will work for
> POV... [...]
Precisely. That's why I'm creating Prism, so mini-languages can be
designed to work together. Before the fact instead of after the fact.
> [...] I don't see how the prisim approach will help this situation.
I hope I've explained it!
Jim
Prism is at http://www.teleport.com/~sphere
PS: On IRC, you asked for some references on mini-language research.
I've attached a web page from DSL '97 (DSL is "Domain-specific
language," the technical term for "mini-language") which should give you
a starting point.
--------------D917655DC7B0E17539051175
Content-Type: text/html; charset=us-ascii;
name="index.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="index.html"
<HTML><HEAD> <TITLE>
Domain-Specific Languages Workshop - Schedule
</TITLE> </HEAD>
<BODY>
<H1 align=center>
<TABLE>
<TR>
<TD valign=top>
<P>
<H1 align=center>
DSL '97 -
First
<a href="http://www.acm.org">ACM</a>
<a href="http://www.acm.org/sigplan/">SIGPLAN</a><br>
<a href="index.html"> Workshop on Domain-Specific Languages </a><br>
January 18, 1997 <br>
Paris, France <br>
(in association with POPL '97)
</H2>
</H1>
</P>
</TD>
<TD>
<PRE> </PRE>
</TD>
<TD>
<img SRC="acmlogo.gif" align=top>
</TD>
</TR>
</TABLE>
</H1>
<HR>
The first ACM-SIGPLAN Workshop on Domain-Specific Languages was held
at the Sorbonne in Paris, France, on January 18, 1997.
This page contains the technical program of that workshop,
with links to obtain the papers presented there, and in some cases
the slides used in the author's presentation.
<P>
The proceedings were distributed in hard-copy to the
workshop participants.
All papers are provided here in (uncompressed) Postscript
format.
<P>
Papers should be referenced as appearing in the Proceedings
of DSL '97, University of Illinois Computer Science Report
(no number);
the URL of this page (<code>www-sal.cs.uiuc.edu/~kamin/dsl</code>)
should also be given.
Most of the electronic versions of the papers included here
lack page numbers, so for citation purposes they are given after the titles.
<HR>
<P>
<strong>9.00-10.00    Invited talk -
David Weiss (Lucent Technologies) </strong> <br>
<blockquote>
<em>Creating Domain-Specific Languages: The FAST Process</em>
<P>
A current trend in manufacturing is to design the
manufacturing process and the product concurrently. The
goal is to make the product easy and fast to produce by the
manufacturing process. Although software is not
manufactured, the techniques needed to achieve the goal of
easily producible software exist. Just as with
manufacturing, the problem is how to organize the software
production process and the products to eliminate rework. One
solution lies in viewing system production as creating
different members of a family, rather than creating a new
system each time requirements change.
<P>
Central to the approach is finding the appropriate
abstractions for the family, creating a language for
describing them, and then translating descriptions of family
members into deliverable software. The family-oriented,
abstraction, specification, and translation (FAST) process
is a systematic process for doing so. FAST incorporates
ideas from language development, rapid prototyping,
application generators, and domain analysis. It is being
tried in a variety of domains within Lucent Technologies.
Based on early estimations from these trials we expect
significant improvements in productivity based on
significant changes in how software developers do their
jobs. In this talk I will give an overview of the FAST
process, some examples of domains and domain-specific
languages that we have created for them, and estimates of
the productivity improvements in these domains.
<P>
(<A HREF="slides/weiss-slides.ps">David's slides</A> (2.1Mb).)
</blockquote>
<P>
10.00-10.30    Break
<P>
<strong>10.30-12.30    Session 1 - Languages </strong>
  <em>(Session chair: Chris Ramming, AT&T Research)</em>
<br>
<A HREF="papers/basu.ps">
<em>A Language-Based Approach to Protocol Construction</em>
</A>
(pages 1-15)<br>
   Anindya Basu, Mark Hayden, Greg Morrisett, & Thorsten von Eiken
(Cornell University)<br>
  
(<A HREF="slides/basu-slides.ps">Anindya's slides.</A> He says they
may not ghostview due to funny fonts, but should print okay.)
<br>
<A HREF="papers/bruce.ps">
<em>What makes a good domain-specific language?</em>
</A>
(pages 17-35)<br>
   David Bruce (Defence Evaluation and Research Agency, UK)
<br>
   (<A HREF="slides/bruce-slides.ps">David's slides</A>)
<br>
<A HREF="papers/yoder.ps">
<em>Domain-specific and general-purpose aspects of spreadsheet languages</em>
</A>
(pages 37-47)<br>
   Alan Yoder & David Cohn (Univ. of Notre Dame)<br>
<A HREF="papers/cowan.ps">
<em>Microlanguages for operating system specialization</em>
</A>
(pages 49-57)<br>
  
Calton Pu, Andrew Black, Crispin Cowan, Jonathan Walpole (OGI),<br>
  
Charles Consel (Univ. of Rennes/IRISA)
<BR>
   (Andrew's slides (<A HREF="slides/black-slides.pdf">PDF</A>,
<A HREF="slides/black-slides.ps">Postscript</A>))
<br>
<P>
12.30-2.00    Lunch break
<P>
<strong>2.00-3.30    Session 2 - Design </strong>
  <em>(Session chair: Paul Hudak, Yale)</em><br>
<A HREF="papers/nakatani.ps">
<em>Jargons and infocentrism</em>
</A>
(pages 59-74)<br>
   Lloyd Nakatani (Lucent Tech.) & Mark Jones (AT&T) <br>
   (<A HREF="slides/nakatani-slides.ps">Lloyd and Mark's slides</A>)
<br>
<A HREF="papers/kiczales.ps">
<em>Aspect Oriented Programming</em>
</A>
(pages 75-88)<br>
   Gregor Kiczales, John Irwin, John Lamping, Jean-Marc Loingtier,
Cristina Lopes,<br>
   Chris Maeda, Anurag Mendhekar (Xerox PARC) <br>
   (Note: PostScript version of this paper is 2.7MB; it is
also available in <A HREF="papers/kiczales.doc">Microsoft Word format</A>,
at 178 KB (!).)<br>
<A HREF="papers/saraswat.ps">
<em>cc - A generic framework for domain-specific languages</em>
</A>
(pages 89-96)<br>
   Markus Fromherz, Vineet Gupta (Xerox PARC), & Vijay Saraswat (AT&T)<br>
<P>
3.30-3.45    Break
<P>
<strong>3.45-4.45    Session 3 - Tools </strong>
  <em>(Session chair: John Launchbury, OGI)</em><br>
<A HREF="papers/pfahler.ps">
<em>Language Design and Implementation by Selection</em>
</A>
(pages 97-108)<br>
    Peter Pfahler & Uwe Kastens (Univ. of Paderborn)
<br>
   
(<A HREF="slides/pfahler.tgz">Peter's slides</A>, in gzipped tar format)
<br>
<A HREF="papers/van-deursen.ps">
<em>Little languages, little maintenance?</em>
</A>
(pages 109-127)<br>
   
Arie van Deursen & Paul Klint (CWI, Amsterdam)
<br>
   
(<A HREF="slides/van-deursen-slides.ps">Arie's slides</A>)
<br>
<P>
4.45-5.00    Break
<P>
<strong>5.00-6.30    "Open mike" session </strong><br>
<blockquote>
<em>Topic: Principles of domain-specific language design:
do we know them? do they exist?
</em>
<P>
This will be a group discussion,
organized around five-minute "position statements."
All who wish to do so are invited to give such a position statement,
possibly accompanied by a slide or
two; we will fit in as many as possible, while also allowing for
a full discussion of the points made in each statement.
The intention is that the position statements will concern general questions,
such as the one posed in the discussion topic,
about the future of dsl's as a field of research and technology.
We hope to have all of
the workshop attendees participate, if not as speakers then
as active participants in the discussion.
<P>
If you want to present a position statement, please write to the
program committee chairman, <a HREF="mailto:s-kamin@uiuc.edu">Sam Kamin</a>,
and so indicate.
This will help make the organization of this session a little bit easier.
</blockquote>
<H3>
Invited Speaker
</H3>
<p>
David Weiss of Lucent Technologies will speak on the role of domain-
specific languages in software engineering. Dr. Weiss is leader
of the FAST (Family-oriented Abstraction and Specification
Technique) project at Lucent, which seeks to extract useful
abstractions from on-going software projects and incorporate
them into special-purpose languages to enhance productivity.
<p>
<h3>
Program Committee
</h3>
<ul>
<li>
<A HREF="http://www.isi.edu/software-sciences/balzer-home.html">
Bob Balzer</A>, <EM>Information Sciences Institute, USC, USA</EM>
<li>
<A HREF="http://www.research.digital.com/SRC/personal/Luca_Cardelli/home.html">
Luca Cardelli</A>, <EM>Digital, SRC, USA</EM>
<li>
<A HREF="http://www.dna.lth.se/home/Gorel_Hedin/">
Görel Hedin</A>, <EM>Lund University, Sweden</EM>
<li>
<A HREF="http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/hudak-paul.html">
Paul Hudak</A>, <EM>Yale University, USA</EM>
<li>
<A HREF="http://www-sal.cs.uiuc.edu/~kamin">
Sam Kamin</A>, <EM>University of Illinois at Urbana-Champaign, USA</EM> (chair)
<li>
<A HREF="http://www.uni-paderborn.de/cs/uwe.html">Uwe Kastens</A>,
<EM>University of Paderborn, Germany</EM>
<li>
<A HREF=:"http://www.cse.ogi.edu/~jl/">
John Launchbury</A>, <EM>Oregon Graduate Institute, USA</EM>
<li>
<A HREF="http://usenix.org/~jcr">
Chris Ramming</A>, <EM>AT&T Research, USA</EM>
</ul>
<H3>Acknowledgements</H3>
<P>
The Program Committee would like to thank the following individuals
for reviewing workshop submissions:
Gary Ling, John Peterson, Alastair Reid, Martin Sulzmann,
and Mark Tullsen.
<P>
We would also like to thank the organizers of POPL, particularly
Peter Lee and Fritz Henglein (general chairs)
for their support of the workshop and
Radhia Cousot (local arrangements)
for making the arrangements so painless for the workshop committee,
and the SIGPLAN Executive Committee for approving
SIGPLAN sponsorship of this event.
<HR>
<p>
<EM>Page last updated: 1/7/97</EM>
</BODY></HTML>
--------------D917655DC7B0E17539051175--