[e-cvs] cvs commit: e/doc/elang/grammar quasi-terms.html dispatchee.html quasi-overview.html quasi-xml.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Tue, 6 Nov 2001 22:10:09 -0500
markm 01/11/06 22:10:09
Modified: doc Makefile toc.txt
doc/download index.html which.html
doc/download/0-8-10alpha index.html
doc/download/0-8-10beta index.html
doc/download/images pedigree.gif pedigree.sdr
doc/elang/grammar dispatchee.html quasi-overview.html
quasi-xml.html
Added: doc/elang/grammar quasi-terms.html
Log:
Hooking up new release. Start on new quasiliteral on TermTrees page
Revision Changes Path
1.41 +8 -4 e/doc/Makefile
Index: Makefile
===================================================================
RCS file: /cvs/e/doc/Makefile,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- Makefile 2001/09/14 01:36:17 1.40
+++ Makefile 2001/11/07 03:10:08 1.41
@@ -13,7 +13,7 @@
all: buttons javadocs tarballs
buttons:
- $(STLE) $(TOP)/src/esrc/scripts/ButtonPointer.e
+ $(STLE) $(TOP)/src/esrc/scripts/ButtonPointer.e $(TOP)/doc
ode:
(cd elib/capability/ode; ./compose.e)
@@ -37,7 +37,7 @@
ER=org.erights.e
_packages:
- (cd $(TOP)/src/jsrc; find net org -name '*.java') | \
+ (cd $(TOP)/src/jsrc; find antlr net org -name '*.java') | \
grep -v "/CVS/" | \
sed 's@/[^/]*$$@@' | sort|uniq | sed 's@/@.@g' \
> packages.tmp
@@ -68,13 +68,15 @@
-group "ELang: Implementing The E Language" \
"$(ER).elang.*" \
-group "ELang Support" \
- "org.erights.build:org.apache.oro.text.regex:org.capml.*" \
+ "org.erights.build:org.capml.*:org.quasiliteral*" \
-group "Elmer: An Interactive E command line & scratchpad" \
"$(ER).ui.*" \
-group "ERTP: Transfering Assayable Electronic Rights" \
"net.ertp*" \
-group "Meta: Sugaring and Deflecting Java Classes" \
"$(ER).meta.*" \
+ -group "Third Party Tools" \
+ "org.apache.oro.text.regex:antlr*" \
-header "$(HEADER)" \
-bottom "$(BOTTOM)" \
@packages.tmp
@@ -106,13 +108,15 @@
-group "ELang: Implementing The E Language" \
"$(ER).elang.*" \
-group "ELang Support" \
- "org.erights.build:org.apache.oro.text.regex:org.capml.*" \
+ "org.erights.build:org.capml.*:org.quasiliteral*" \
-group "Elmer: An Interactive E command line & scratchpad" \
"$(ER).ui.*" \
-group "ERTP: Transfering Assayable Electronic Rights" \
"net.ertp*" \
-group "Meta: Sugaring and Deflecting Java Classes" \
"$(ER).meta.*" \
+ -group "Third Party Tools" \
+ "org.apache.oro.text.regex:antlr*" \
-header "$(HEADER)" \
-bottom "$(BOTTOM)" \
@packages.tmp
1.46 +6 -0 e/doc/toc.txt
Index: toc.txt
===================================================================
RCS file: /cvs/e/doc/toc.txt,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- toc.txt 2001/09/16 13:34:25 1.45
+++ toc.txt 2001/11/07 03:10:08 1.46
@@ -121,6 +121,7 @@
prim-expr.html
patterns.html
quasi-overview.html
+ quasi-terms.html
quasi-xml.html
dispatchee.html
lexical.html
@@ -291,6 +292,11 @@
unix-bin.html
unix-src.html
0-8-10alpha/
+ windows-bin.html
+ windows-src.html
+ unix-bin.html
+ unix-src.html
+ 0-8-10beta/
windows-bin.html
windows-src.html
unix-bin.html
1.32 +9 -4 e/doc/download/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/download/index.html,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- index.html 2001/09/30 23:43:15 1.31
+++ index.html 2001/11/07 03:10:08 1.32
@@ -68,10 +68,15 @@
</tr>
<tr>
<td>--></td>
- <td><b><a href="0-8-10alpha/index.html">0.8.10alpha1</a></b>: The first
- release of E to be distributed (except for 3vat introductions), persistent
- (sort-of), and to support (and confine) locally untrusted code. This
- is the current main release.</td>
+ <td><b><a href="0-8-10beta/index.html">0.8.10beta1</a></b>: This is
+ the current main release. Antlr bundled in, and used as basis of new
+ Term / Functor trees.</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td><a href="0-8-10alpha/index.html">0.8.10alpha1</a>: The first release
+ of E to be distributed (except for 3vat introductions), persistent
+ (sort-of), and to support (and confine) locally untrusted code.</td>
</tr>
<tr>
<td> </td>
1.35 +13 -7 e/doc/download/which.html
Index: which.html
===================================================================
RCS file: /cvs/e/doc/download/which.html,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- which.html 2001/09/30 23:43:15 1.34
+++ which.html 2001/11/07 03:10:08 1.35
@@ -52,18 +52,24 @@
<tr>
<td>
<map name="navmap">
- <area shape="rect" coords="83,185,176,217" href="0-8-10alpha/index.html">
- <area shape="rect" coords="301,231,390,259" href="stl-0-8-9-t-1/index.html">
- <area shape="rect" coords="92,444,164,475" href="stl-0-8-9-t/index.html">
- <area shape="rect" coords="252,539,353,568" href="0-8-9-1/index.html">
+ <area shape="rect" coords="85,302,178,334" href="0-8-10alpha/index.html">
+ <area shape="rect" coords="89,132,172,162" href="0-8-10beta/index.html">
+ <area shape="rect" coords="306,249,395,277" href="stl-0-8-9-t-1/index.html">
+ <area shape="rect" coords="95,559,167,590" href="stl-0-8-9-t/index.html">
+ <area shape="rect" coords="252,652,353,681" href="0-8-9-1/index.html">
</map>
- <img src="images/pedigree.gif" border=0 usemap="#navmap" ismap width="415" height="764"></td>
+ <img src="images/pedigree.gif" border=0 usemap="#navmap" ismap width="420" height="880"></td>
<td>
<ul>
<li>
<p>The current release of <b><i><font color="#009000">E</font></i></b>
- is <a href="0-8-10alpha/index.html">0.8.10alpha1</a>, which
- is a hot off the presses first draft of the planned 0.8.10 release.
+ is <a href="0-8-10beta/index.html">0.8.10beta1</a>. Antlr bundled
+ in, and ASTs converted to and from the new Term / Functor trees.
+ Also, many bug fixes.</p>
+ </li>
+ <li>
+ <p><a href="0-8-10alpha/index.html">0.8.10alpha1</a>, which is
+ a hot off the presses first draft of the planned 0.8.10 release.
Except for those working on E compilation, this is believed
to be the best version of E. However, since it's new, you may
run into new problems. If so, please <a href="https://bugs.sieve.net/bugs/?func=addbug&group_id=16380">report
1.8 +1 -1 e/doc/download/0-8-10alpha/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/download/0-8-10alpha/index.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- index.html 2001/09/30 23:43:16 1.7
+++ index.html 2001/11/07 03:10:08 1.8
@@ -35,7 +35,7 @@
<tr>
<td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="../stl-0-8-9-t-1/index.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: E stl-0.8.9t.1a Download and Install E" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><a href="windows-bin.html"><img src="../../images/first.gif" width="32" height="64" alt="1st child: E 0.8.10alpha1: Installing on Windows" border="0"></a><!-- #EndEditable --></td>
- <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><img src="../../images/next-gray.gif" width="64" height="32"><!-- #EndEditable --></td>
+ <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="../0-8-10beta/index.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: E 0.8.10beta1 Download and Install E" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
1.2 +8 -2 e/doc/download/0-8-10beta/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/download/0-8-10beta/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html 2001/11/06 18:33:17 1.1
+++ index.html 2001/11/07 03:10:08 1.2
@@ -136,8 +136,14 @@
<h1><a name="Highlights"></a>Highlights of this Version</h1>
<p>As each of these issues are discussed in email or in the bug tracking
system, we will link the paragraphs below to the relevant roots.</p>
- <h3>Abstract Syntax Trees</h3>
- <p>xx</p>
+ <h3>Term / Functor Trees</h3>
+ <p>As of this release, we have finally chosen a universal abstract syntax
+ tree representation that we can live with and use as a flexible basis
+ for quasi-literal-based match-bind-substitute programming. Our choice
+ leverages Antlr, and resembles Prolog term trees.</p>
+ <p>At first, we tried to be politically correct, and use a standard compatible
+ subset of XML as a basis, as documented <a href="../../elang/grammar/quasi-xml.html">here</a>.
+ </p>
<h3>Many bug fixes</h3>
<ul>
<li>xx</li>
1.2 +40 -41 e/doc/download/images/pedigree.gif
Index: pedigree.gif
===================================================================
RCS file: /cvs/e/doc/download/images/pedigree.gif,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
Binary files /tmp/cvslRdbN8 and /tmp/cvsI6hnb7 differ
1.2 +43 -42 e/doc/download/images/pedigree.sdr
Index: pedigree.sdr
===================================================================
RCS file: /cvs/e/doc/download/images/pedigree.sdr,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
Binary files /tmp/cvsIBGMr9 and /tmp/cvseCRCO8 differ
1.23 +1 -1 e/doc/elang/grammar/dispatchee.html
Index: dispatchee.html
===================================================================
RCS file: /cvs/e/doc/elang/grammar/dispatchee.html,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- dispatchee.html 2001/09/30 23:43:18 1.22
+++ dispatchee.html 2001/11/07 03:10:08 1.23
@@ -33,7 +33,7 @@
<!-- #BeginEditable "Path" -->/ <a href="../index.html">elang</a> / <a href="index.html">grammar</a> <!-- #EndEditable --></td>
</tr>
<tr>
- <td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="quasi-xml.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: Quasi-Literals and XML" border="0"></a><!-- #EndEditable --></td>
+ <td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="quasi-xml.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: Obsolete: Quasi-Literals and XML" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><!-- #EndEditable --></td>
<td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="lexical.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: Lexical Grammar" border="0"></a><!-- #EndEditable --></td>
</tr>
1.26 +1 -1 e/doc/elang/grammar/quasi-overview.html
Index: quasi-overview.html
===================================================================
RCS file: /cvs/e/doc/elang/grammar/quasi-overview.html,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- quasi-overview.html 2001/09/30 23:43:18 1.25
+++ quasi-overview.html 2001/11/07 03:10:08 1.26
@@ -35,7 +35,7 @@
<tr>
<td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="patterns.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: Pattern Grammar" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><!-- #EndEditable --></td>
- <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="quasi-xml.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: Quasi-Literals and XML" border="0"></a><!-- #EndEditable --></td>
+ <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="quasi-terms.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: Quasi-Literals and Term / Functor Trees" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
1.16 +157 -152 e/doc/elang/grammar/quasi-xml.html
Index: quasi-xml.html
===================================================================
RCS file: /cvs/e/doc/elang/grammar/quasi-xml.html,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- quasi-xml.html 2001/09/30 23:43:18 1.15
+++ quasi-xml.html 2001/11/07 03:10:08 1.16
@@ -5,7 +5,7 @@
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<!-- #BeginEditable "doctitle" -->
-<TITLE>Quasi-Literals and XML</TITLE>
+<TITLE>Obsolete: Quasi-Literals and XML</TITLE>
<!-- #EndEditable -->
<meta name="Author" content="Mark S. Miller">
<link rel=author rev=made href="mailto:markm@caplet.com" title="Mark S. Miller">
@@ -33,49 +33,55 @@
<!-- #BeginEditable "Path" -->/ <a href="../index.html">elang</a> / <a href="index.html">grammar</a> <!-- #EndEditable --></td>
</tr>
<tr>
- <td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="quasi-overview.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: QuasiLiterals" border="0"></a><!-- #EndEditable --></td>
+ <td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="quasi-terms.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: Quasi-Literals and Term / Functor Trees" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><!-- #EndEditable --></td>
<td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="dispatchee.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: Methods and Matchers" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
<TD ALIGN="RIGHT">
- <P ALIGN="RIGHT"><FONT SIZE="7"><!-- #BeginEditable "BigTitle" --><b>Quasi-Literals<br>
+ <P ALIGN="RIGHT"><FONT SIZE="7"><!-- #BeginEditable "BigTitle" --><b>
+ <font size="5" color="#FF0000">Obsolete:<br>
+ </font>Quasi-Literals<br>
and XML</b><!-- #EndEditable --></FONT>
</TD>
</TR>
</TABLE>
<hr>
- <!-- #BeginEditable "LongBody" -->
- <p><i>XML's greatest strength is also its greatest weakness. XML standardizes
- a single universal meta-notation for expressing a vast variety of different
- types of semi-structured data. The advantage of this approach is that
- generic tools can be built that apply to all data expressed in this notation.
- The disadvantage of shoehoring all data into a one-size-fits-all notation
- is that this "universal" notation will be a very poor fit for many particular
- types of data. Historically, rather than having a universal notation,
- the world created a vast number of specialized notations, each optimized
- for its particular subject matter. This approach has exactly the opposite
+ <!-- #BeginEditable "LongBody" -->
+ <p><font color="#FF0000">Note: This document is now obsolete, but is being
+ preserved as a record of our plans preceding our decision to use Antlr-based
+ Term / Functor trees instead, as will be explained <a href="quasi-terms.html">here</a>.</font></p>
+ <hr>
+ <p><i>XML's greatest strength is also its greatest weakness. XML standardizes
+ a single universal meta-notation for expressing a vast variety of different
+ types of semi-structured data. The advantage of this approach is that
+ generic tools can be built that apply to all data expressed in this notation.
+ The disadvantage of shoehoring all data into a one-size-fits-all notation
+ is that this "universal" notation will be a very poor fit for many particular
+ types of data. Historically, rather than having a universal notation,
+ the world created a vast number of specialized notations, each optimized
+ for its particular subject matter. This approach has exactly the opposite
advantages and disadvantages of the XML approach. </i> </p>
- <p> <i>This paper shows how, by leveraging E's <a href="quasi-overview.html">QuasiParser
- Framework</a>, we can have the best of both worlds while maintaining XML
+ <p> <i>This paper shows how, by leveraging E's <a href="quasi-overview.html">QuasiParser
+ Framework</a>, we can have the best of both worlds while maintaining XML
compatibility. </i></p>
- <p>This paper describes a <i>proposal</i> for enhancing E, rather than features
- currently in E or decisions that have already been made. We welcome your
+ <p>This paper describes a <i>proposal</i> for enhancing E, rather than features
+ currently in E or decisions that have already been made. We welcome your
feedback on the proposal so we may make better decisions prior to implementation.</p>
- <div>
+ <div>
<h2 class="title">Making XML Usable</h2>
<p>We propose to use three technologies to improve the usability of XML:</p>
<ul>
- <li>
+ <li>
<p>A Parser Generator whose actions build XML/DOM trees.</p>
<p>This technology creates <i>notational interoperability</i>.</p>
</li>
- <li>
- <p>A QuasiParser for creating quasi-literal XML expressions and quasi-literal
+ <li>
+ <p>A QuasiParser for creating quasi-literal XML expressions and quasi-literal
XML patterns</p>
- <p>With this technology, programmers can write transformation code
- in the <i>match-bind-substitute</i> programming paradigm in the
+ <p>With this technology, programmers can write transformation code
+ in the <i>match-bind-substitute</i> programming paradigm in the
context of general programmability.</p>
</li>
<li>Adoption of <a href="http://www.docuverse.com/smldev/">Minimal-XML</a>,
@@ -84,16 +90,16 @@
is a downward compatible subset of XML, and (using the <a href="http://www.docuverse.com/min/#resource">Minimizer</a>)
most of XML can be embedded in Minimal-XML.</li>
</ul>
- <p>Each of these technologies by themselves make XML significantly more
- usable. In combination, they amplify each other, enabling programmers
+ <p>Each of these technologies by themselves make XML significantly more
+ usable. In combination, they amplify each other, enabling programmers
greater ease at manipulating XML.</p>
- <div>
+ <div>
<h3 class="title">Notational Interoperability</h3>
- <p>Abstracting away from the particulars of XML syntax, what is the
- essential <i>idea</i>of XML? XML expresses trees of symbols in a manner
- very similar (syntax aside) to Lisp S-Expressions or Prolog term-trees
- (sometimes called Herbrand trees). Lisp S-Expressions and Prolog term-trees
- are usually thought of primarily as data structures, and only secondarily
+ <p>Abstracting away from the particulars of XML syntax, what is the
+ essential <i>idea</i>of XML? XML expresses trees of symbols in a manner
+ very similar (syntax aside) to Lisp S-Expressions or Prolog term-trees
+ (sometimes called Herbrand trees). Lisp S-Expressions and Prolog term-trees
+ are usually thought of primarily as data structures, and only secondarily
as notations. What if we take this perspective to XML as well?</p>
<p>It turns out there already is a well standardized tree data structure
that corresponds one-for-one with XML: the <a href="http://www.w3.org/DOM/">Document
@@ -112,80 +118,80 @@
-- both to other tools and to other sites -- while still allowing
programmers to manipulate specialized forms of data in notations suited
for that form of data.</p>
- <p><i>Minimal-XML is the subset of XML that most closely corresponds
+ <p><i>Minimal-XML is the subset of XML that most closely corresponds
to the good stuff -- the S-Expression-like functionality.</i></p>
</div>
- <div>
+ <div>
<h3 class="title">Match-Bind-Substitute Programming</h3>
<p>So how should DOM trees be examined and manipulated by programmers?
Currently programmers are stuck between two bad choices:</p>
<ul>
- <li>
+ <li>
<p>They can program to the DOM API explicitly.</p>
- <p>Occasionally, this is the right thing. More often this results
- in expressing concepts far too indirectly. Think about the difference
- between driving <i>vs.</i> explaining to someone how to drive.
- This is like the difference between expressing mostly-literal
- data mostly literally <i>vs.</i> having to write code to generate
+ <p>Occasionally, this is the right thing. More often this results
+ in expressing concepts far too indirectly. Think about the difference
+ between driving <i>vs.</i> explaining to someone how to drive.
+ This is like the difference between expressing mostly-literal
+ data mostly literally <i>vs.</i> having to write code to generate
all the data.</p>
</li>
- <li>
+ <li>
<p>They can write transformations in XSL.</p>
- <p>XSL is a specialized language built specifically for transforming
- XML, into XML or other notations, but not for transforming other
- notations into XML. Most damaging, XSL is not Turing complete
- (does not have the power of any general purpose programming language),
- and so is severely restricted in the transformations it can express.
- Nevertheless, it is attractive for simple transformations precisely
+ <p>XSL is a specialized language built specifically for transforming
+ XML, into XML or other notations, but not for transforming other
+ notations into XML. Most damaging, XSL is not Turing complete
+ (does not have the power of any general purpose programming language),
+ and so is severely restricted in the transformations it can express.
+ Nevertheless, it is attractive for simple transformations precisely
<i>because</i> of its support for match-bind-substitute programming.</p>
</li>
</ul>
- <p>What is the match-bind-substitute style, and how is it used in XSL?
+ <p>What is the match-bind-substitute style, and how is it used in XSL?
Consider the following snippet of XSL:</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300"><xsl:template match="Sect1/Title">
<H2><xsl:apply-templates/></H2>
</xsl:template></font>
</pre>
</blockquote>
- <p>The first line is a pattern that matches against an XML subtree exactly
- when its root is a <i>Sect1</i> tag and it contains <i>Title</i>-tagged
- subtree as an immediate child. Besides matching, this pattern also
- <i>binds</i> the children of <i>Title</i> to an implicit variable
- used (implicitly again) in the next line. Though this pattern is performing
- a match-bind it does not look like the data it matches. In more complex
- XSL cases involving containment, the pattern does have a <i>partially
- literal</i> resemblance (in certain regards) to the data it matches
+ <p>The first line is a pattern that matches against an XML subtree exactly
+ when its root is a <i>Sect1</i> tag and it contains <i>Title</i>-tagged
+ subtree as an immediate child. Besides matching, this pattern also
+ <i>binds</i> the children of <i>Title</i> to an implicit variable
+ used (implicitly again) in the next line. Though this pattern is performing
+ a match-bind it does not look like the data it matches. In more complex
+ XSL cases involving containment, the pattern does have a <i>partially
+ literal</i> resemblance (in certain regards) to the data it matches
against, so we would call this a <i>quasi-literal pattern</i>.</p>
- <p>The second line shows the flip side, a <i>quasi-literal expression</i>.
- An expression evaluates to the data to be produced. A quasi-literal
- expression is an expression that looks partially like the data it
- will produce. In this case, the data to be produced is HTML bracketed
- by "<code><H2></code>" and "<code></H2></code>" tags
- just as they appear in the expression. The non-literal parts of the
- expression are those prefixed with "<code><xsl:</code>". These
- are evaluated according to different rules and the results <i>substituted</i>
- in to the enclosing literal context. However, these extra rules are
- simply the primitives built into XSL, and despite the name, are not
+ <p>The second line shows the flip side, a <i>quasi-literal expression</i>.
+ An expression evaluates to the data to be produced. A quasi-literal
+ expression is an expression that looks partially like the data it
+ will produce. In this case, the data to be produced is HTML bracketed
+ by "<code><H2></code>" and "<code></H2></code>" tags
+ just as they appear in the expression. The non-literal parts of the
+ expression are those prefixed with "<code><xsl:</code>". These
+ are evaluated according to different rules and the results <i>substituted</i>
+ in to the enclosing literal context. However, these extra rules are
+ simply the primitives built into XSL, and despite the name, are not
extensible.</p>
- <p>The E quasi-parser framework combines the directness of XSL-style
- match-bind-substitute programming with the power of general purpose
- programming. The E programmer can escape the dichotomy presented by
+ <p>The E quasi-parser framework combines the directness of XSL-style
+ match-bind-substitute programming with the power of general purpose
+ programming. The E programmer can escape the dichotomy presented by
the above two bullets.</p>
</div>
- <div>
+ <div>
<h3 class="title">Example: MathML</h3>
- <p> <a href="http://www.w3.org/TR/REC-MathML/chapter2.html#sec2.1.2">MathML</a>
- is a particularly notorious example of the price XML pays for using
+ <p> <a href="http://www.w3.org/TR/REC-MathML/chapter2.html#sec2.1.2">MathML</a>
+ is a particularly notorious example of the price XML pays for using
a single generic syntax for all jobs. In MathML, the simple expression</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300">x<sup><font size="-1">2</font></sup> + x<sup><font size="-1">3</font></sup></font>
</pre>
</blockquote>
<p>is expressed as</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300"><apply>
<plus/>
@@ -202,41 +208,41 @@
</apply></font>
</pre>
</blockquote>
- <p>This small example, though unpleasant, is still something humans
- can deal with. However, the problem gets so bad with large examples
- that it's recommended for humans to deal with equations only through
- graphical wysiwyg equation editors (such as <a href="http://www.webeq.com/">WebEQ</a>).
+ <p>This small example, though unpleasant, is still something humans
+ can deal with. However, the problem gets so bad with large examples
+ that it's recommended for humans to deal with equations only through
+ graphical wysiwyg equation editors (such as <a href="http://www.webeq.com/">WebEQ</a>).
That's fine for human editors, but what about human programmers?</p>
- <p>Further, what about XML DTDs defined for narrower domains, without
- the broad interest that would produce specialized wysiwyg editors?
- The appendix below shows an American Option written in the Financial
- Products Markup Language, or FpML, the emerging standard for representing
- derivative intruments. A glance shows the notation to be at least
- as unwieldy as MathML, but FPML advocates offer no alternative to
- their notational burden. Increasingly, XML is being applied to non-document
- data. MathML is a representative small example of the issues that
+ <p>Further, what about XML DTDs defined for narrower domains, without
+ the broad interest that would produce specialized wysiwyg editors?
+ The appendix below shows an American Option written in the Financial
+ Products Markup Language, or FpML, the emerging standard for representing
+ derivative intruments. A glance shows the notation to be at least
+ as unwieldy as MathML, but FPML advocates offer no alternative to
+ their notational burden. Increasingly, XML is being applied to non-document
+ data. MathML is a representative small example of the issues that
result.</p>
- <p>Programmers need to write code that generates, recognizes, and transforms
- XML. For an example transformation that should be easy, consider symbolic
- differentiation of simple mathematical expressions, as is taught to
- undergraduates in introductory Lisp and Prolog courses. Since XML
- transformations are normally written in XSL, one would expect that
- symbolic differentiation could easily be expressed in XSL. Unfortunately,
- XSL, with its fixed set of primitives, runs out of steam too quickly.
- I was not able to figure out how to write it at all in XSL, and neither
+ <p>Programmers need to write code that generates, recognizes, and transforms
+ XML. For an example transformation that should be easy, consider symbolic
+ differentiation of simple mathematical expressions, as is taught to
+ undergraduates in introductory Lisp and Prolog courses. Since XML
+ transformations are normally written in XSL, one would expect that
+ symbolic differentiation could easily be expressed in XSL. Unfortunately,
+ XSL, with its fixed set of primitives, runs out of steam too quickly.
+ I was not able to figure out how to write it at all in XSL, and neither
could other programmers I asked.</p>
- <p>Turning to the other currently available alternative, let's see how
- symbolic differentiation looks in Java manipulating DOM trees. For
- compactness, we only show the rules necessary for differentiating
+ <p>Turning to the other currently available alternative, let's see how
+ symbolic differentiation looks in Java manipulating DOM trees. For
+ compactness, we only show the rules necessary for differentiating
the two operators in our example, addition and exponentiation-to-a-constant.</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300">...show symbolic differentiation in Java on DOM trees...</font>
</pre>
</blockquote>
- <p>By contrast, using the XML QuasiParser technology described below,
+ <p>By contrast, using the XML QuasiParser technology described below,
we can express the same transformation in E as</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300">def deriv(expr, var) :any {
switch(expr) {
@@ -254,55 +260,55 @@
</pre>
</blockquote>
<p>The last 3 lines could have instead been written as</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300"> math`${deriv(a, var)} + $(deriv(b, var)}`</font>
</pre>
</blockquote>
- <p>depending on your taste. This is not only compact, readable, and
- maintainable, it also states the transformation rules in a notation
- recognizable to the relevant subject domain specialists -- in this
- case, to mathematicians. Despite the notational shift, the output
- is a DOM tree which can be written out as a new MathML expression
- in XML. What do we need to build to make this example possible? Below,
+ <p>depending on your taste. This is not only compact, readable, and
+ maintainable, it also states the transformation rules in a notation
+ recognizable to the relevant subject domain specialists -- in this
+ case, to mathematicians. Despite the notational shift, the output
+ is a DOM tree which can be written out as a new MathML expression
+ in XML. What do we need to build to make this example possible? Below,
we build up to this example in stages.</p>
</div>
- <div>
+ <div>
<h3 class="title">Usable XML is Three Stages</h3>
- <p>First we explain the existing QuasiParser framework already integrated
- into E. Then we explain how we will extend this, in three stages,
+ <p>First we explain the existing QuasiParser framework already integrated
+ into E. Then we explain how we will extend this, in three stages,
into a system able to express the above examples.</p>
<ol>
- <li>
+ <li>
<p>An XML QuasiParser</p>
- <p>Enables programmers to write transformation code in the match-bind-substitute
- style, a style whose power has been amply demonstrated by XSL,
+ <p>Enables programmers to write transformation code in the match-bind-substitute
+ style, a style whose power has been amply demonstrated by XSL,
Prolog, and Perl.</p>
</li>
- <li>
+ <li>
<p>Parser Generation with XML Actions</p>
- <p>Enables programmers to create specialized notations for expressing
+ <p>Enables programmers to create specialized notations for expressing
data in particular DTDs, while maintaining XML compatibility.</p>
</li>
- <li>
+ <li>
<p>Generating QuasiParsers Instead</p>
- <p>Enables the application of these new notations to the match-bind-substitute
+ <p>Enables the application of these new notations to the match-bind-substitute
programming of XML transformations.</p>
</li>
</ol>
</div>
</div>
- <div>
+ <div>
<h2 class="title">Step 1: An XML QuasiParser</h2>
</div>
- <div>
+ <div>
<p><font color="#FF0000">To be written...</font></p>
- <div>
+ <div>
<h3 class="title">Example: Symbolic Differentiation in XML Notation</h3>
- <p>Armed only with the XML QuasiParser itself, we can express XML transformations
- using quasi-literal XML notation. For example, our symbolic differentiation
+ <p>Armed only with the XML QuasiParser itself, we can express XML transformations
+ using quasi-literal XML notation. For example, our symbolic differentiation
routine could now be written:</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300">def deriv(expr, var) :any {
switch(expr) {
@@ -345,15 +351,15 @@
</blockquote>
</div>
</div>
- <div>
+ <div>
<h2 class="title">Step 2: Parser Generation with XML Actions</h2>
<p><font color="#FF0000">To be written...</font></p>
- <div>
+ <div>
<h3 class="title">Example: Defining DTD-Specific Grammars</h3>
- <p>The following grammar is written in a hypothetical variant of BYacc/Java
- or ANTLR in which the actions are XML quasi-literal strings as supported
+ <p>The following grammar is written in a hypothetical variant of BYacc/Java
+ or ANTLR in which the actions are XML quasi-literal strings as supported
by Step 1 above. (We would probably create an ANTLR wrapper.)</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300">expr:
mult
@@ -375,26 +381,26 @@
</pre>
</blockquote>
<p>If the generated parser is called Math, then executing</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300">Math("x**2 + x**3")</font>
</pre>
</blockquote>
- <p>produces the same DOM tree that would be produced by parsing the
- corresponding XML. From this DOM tree, the corresponding XML can be
+ <p>produces the same DOM tree that would be produced by parsing the
+ corresponding XML. From this DOM tree, the corresponding XML can be
trivially output.</p>
- <p>But a specialized data set isn't an island. A document should properly
- be able to contain multiple different kinds of data. We would like
- to express each kind of data in the notation most suitable for it,
- while allowing these data items to be embedded in each other. Our
+ <p>But a specialized data set isn't an island. A document should properly
+ be able to contain multiple different kinds of data. We would like
+ to express each kind of data in the notation most suitable for it,
+ while allowing these data items to be embedded in each other. Our
XML QuasiParser already solves this for us. The expression</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300">xml`<Sect1><Para>For example, ${Math("x**2 + x**3")} is nice</Para></Sect1>`</font>
</pre>
</blockquote>
<p>Produced the same DOM tree as this XML:</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300"><Sect1>
<Para>For example, <apply>
@@ -415,29 +421,29 @@
</blockquote>
</div>
</div>
- <div>
+ <div>
<h2 class="title">Step 3: Generating QuasiParsers Instead</h2>
<p><font color="#FF0000">To be written...</font></p>
</div>
- <div>
+ <div>
<h2 class="title">Conclusions</h2>
- <p>The code in the Appendix below is a typical sample use of FpML, the
- Financial Products Markup Language, to represent a derivative -- in
- this case, an American Call Option. This code and others like it are
- <a href="http://www.fpml.com/documents/standard/FpML-10b2/FpML-10b2.html">posted</a>
+ <p>The code in the Appendix below is a typical sample use of FpML, the
+ Financial Products Markup Language, to represent a derivative -- in
+ this case, an American Call Option. This code and others like it are
+ <a href="http://www.fpml.com/documents/standard/FpML-10b2/FpML-10b2.html">posted</a>
by FpML advocates, so one may assume that it represents good FpML usage.</p>
- <p>FpML is both an important standard in its own right, and representative
- of what happens when XML is applied to semi-structured data outside
- the "document" paradigm. No where else in the history of computation
- has such a great excess of syntax over semantics been long sustained.
- XML programmers desperately need notational relief! The E QuasiParser
- Framework can provide much of that relief, while maintaining compatibility
+ <p>FpML is both an important standard in its own right, and representative
+ of what happens when XML is applied to semi-structured data outside
+ the "document" paradigm. No where else in the history of computation
+ has such a great excess of syntax over semantics been long sustained.
+ XML programmers desperately need notational relief! The E QuasiParser
+ Framework can provide much of that relief, while maintaining compatibility
.</p>
</div>
- <div>
+ <div>
<h2 class="title">Appendix: An American Call Option in FpML</h2>
<p>The following code is covered by the Mozilla open-source license.</p>
- <blockquote>
+ <blockquote>
<pre>
<font color="#003300"><?xml version="1.0" standalone="no"?>
<!-- Copyright (c) 1999 by J.P.Morgan and PricewaterhouseCoopers.
@@ -643,7 +649,6 @@
</fpml:FpML></font></pre>
</blockquote>
</div>
-
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>
1.1 e/doc/elang/grammar/quasi-terms.html
Index: quasi-terms.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!--last modified on Saturday, October 03, 1998 04:19 PM -->
<HTML><!-- #BeginTemplate "/Templates/pink.dwt" -->
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<!-- #BeginEditable "doctitle" -->
<TITLE>Quasi-Literals and Term / Functor Trees</TITLE>
<!-- #EndEditable -->
<meta name="Author" content="Mark S. Miller">
<link rel=author rev=made href="mailto:markm@caplet.com" title="Mark S. Miller">
<META NAME="description" CONTENT="E: Cryptographic Capabilities for Distributed Smart Contracting">
<META NAME="keywords" CONTENT="p2p, p2p language, p2p computing, p2p objects, secure p2p, p2p capabilities, object oriented p2p,
capability-based p2p, Capability Security, Capabilities, Cryptography, Distributed Objects, Distributed
Language, Distributed Capabilities, Lambda Calculus, Scripting Language, Distributed Language, Persistent
Language, Persistent Capabilities, Persistent Objects, Java Shell, Capability Shell, Scripting Java, Smart
Contracting, Agoric E-Commerce, Open Source, Message pipelining, quasi literal, vat, event loop, granovetter diagram ">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFEEDD" LINK="#0000FF" VLINK="#800080">
<P>
<TABLE BORDER="0" width="100%">
<TR VALIGN="TOP">
<TD WIDTH="10%"> </TD>
<TD>
<P>
<TABLE BORDER="0" WIDTH="100%">
<TR>
<TD ALIGN="LEFT" valign="top">
<table cellpadding="2">
<tr>
<td valign="top" align="left" colspan="3"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a>
<!-- #BeginEditable "Path" -->/ <a href="../index.html">elang</a> / <a href="index.html">grammar</a> <!-- #EndEditable --></td>
</tr>
<tr>
<td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="quasi-overview.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: QuasiLiterals" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><!-- #EndEditable --></td>
<td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="quasi-xml.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: Obsolete: Quasi-Literals and XML" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
<TD ALIGN="RIGHT">
<P ALIGN="RIGHT"><FONT SIZE="7"><!-- #BeginEditable "BigTitle" --><b>
Quasi-Literals<br>
<font size="6">and Term / Functor Trees</font></b><!-- #EndEditable --></FONT>
</TD>
</TR>
</TABLE>
<hr>
<!-- #BeginEditable "LongBody" -->
<p><font color="#FF0000">Note: This page will explain E's current plans
for quasi-literals on symbol trees, but is still terribly incomplete.
In the meantime, <a href="quasi-xml.html">this page</a> should give a
sense for where we're going. It expresses the same set of concepts in
terms of our earlier plans to use Minimal-XML DOM trees.</font></p>
<hr>
<h1 align="center">Match-Bind-Substitute Programming<br>
for<br>
Extensible Symbolic Notations </h1>
<p><font color="#FF0000">*** write overview</font></p>
<ul>
<li>
<p>A Parser Generator whose actions build Term trees.</p>
<p>This technology creates <i>notational interoperability</i>.</p>
</li>
<li>
<p>A QuasiParser generator for creating QuasiParsers, for creating quasi-literal
expressions and quasi-literal patterns</p>
<p>With this technology, programmers can write transformation code in
the <i>match-bind-substitute</i> programming paradigm in the context
of general programmability</p>
</li>
</ul>
<h1>Universal <i>vs </i>Specialized Syntaxes?</h1>
<p>Lisp S-Expressions, Prolog Term Trees, and XML all demonstrate the power
of using a "universal" notation for trees of symbols to represent
information that could have been encoded in a great variety of separately
designed notations. The most common approach to using this power is to
express oneself directly in this universal notation. For example, the
strength of this approach is the most often cited explanation of XML's
popularity: By using a common underlying representation (e.g., XML), generic
tools (e.g. XSLT) can often be written to apply to many particular forms
of symbolic information (e.g. domain-specific XML conforming to a particular
DTD) not known to the tool creator. </p>
<p>However, this approach by itself has a great cost. It would have us forsake
the use of specialized syntaxes optimized for use in specialized domains.
The history of at least Math, Physics, many domains of Engineering, and
especially Computer Science shows the surprising degree to which a well
designed notation can aid human thinking in novel complex domains.</p>
<h3 class="title">Example: Algebraic Expressions</h3>
<p> The simple expression, written in standard math notation as</p>
<blockquote>
<pre>
<font color="#003300">x<sup><font size="-1">2</font></sup> + x<sup><font size="-1">3</font></sup></font>
</pre>
</blockquote>
<p>is expressed in MathML as</p>
<blockquote>
<pre>
<font color="#003300"><apply>
<plus/>
<apply>
<power/>
<ci>x</ci>
<cn>2</cn>
</apply>
<apply>
<power/>
<ci>x</ci>
<cn>3</cn>
</apply>
</apply></font></pre>
</blockquote>
<p><a href="http://www.w3.org/TR/REC-MathML/chapter2.html#sec2.1.2">MathML</a>
is a particularly notorious example of the price XML pays for using a
single generic syntax for all jobs. But even with Lisp E-Expressions,
we might express this as</p>
<blockquote>
<pre>'(plus (power x 2) (power x 3))</pre>
</blockquote>
<p>or, similarly, in Prolog Term Trees as</p>
<blockquote>
<pre>plus(power("x", 2), power("x", 3))</pre>
</blockquote>
<p>While both of these are vast improvements over MathML, they are still
vastly worse <i>for this puirpose</i> than the conventional specialized
algebraic notation. Such is the price of universal notations, even well
designed ones.</p>
<h3>Notational Interoperability: Many Surfaces on One Tree</h3>
<p>*** Explain about Antlr <a href="../../javadoc/antlr/collections/AST.html">ASTs</a>
and <a href="../../javadoc/antlr/Token.html">Tokens</a> and parser generation.</p>
<p>*** Explain bout <a href="../../javadoc/org/quasiliteral/term/Term.html">Term</a>
/ <a href="../../javadoc/org/quasiliteral/term/Functor.html">Functor</a>
trees, and about our universal Term tree syntax.</p>
<p>*** Explain briefly about <a href="../../javadoc/org/quasiliteral/astro/Astro.html">Astro</a>
and <a href="../../javadoc/org/quasiliteral/astro/AstroToken.html">AstroToken</a>.</p>
<div>
<div>
<h1 class="title">Match-Bind-Substitute Programming</h1>
</div>
<div>
<p><font color="#FF0000">*** Show symbolic differentiation</font></p>
<p>By contrast, using the QuasiParser technology described below, we
can express the same transformation in E as</p>
</div>
<div>
<blockquote>
<pre>
<font color="#003300">def deriv(expr, var) :any {
switch(expr) {
match math`$var ** @exp` ? (isConst(exp)) {
math`$exp * $var ** ($exp - 1)`
}
match math`@a + @b` {
def da := deriv(a, var)
def db := deriv(b, var)
math`$da + $db`
}
<font face="Times New Roman, Times, serif"># ...</font>
}
}</font>
</pre>
</blockquote>
<p>The last 3 lines could have instead been written as</p>
<blockquote>
<pre>
<font color="#003300"> math`${deriv(a, var)} + $(deriv(b, var)}`</font>
</pre>
</blockquote>
<p>depending on your taste. This is not only compact, readable, and
maintainable, it also states the transformation rules in a notation
recognizable to the relevant subject domain specialists -- in this
case, to mathematicians. Despite the notational shift, the output
is a Term tree which can be written out as a ...</p>
<p>*** write the rest</p>
</div>
</div>
<div>
<blockquote> </blockquote>
</div>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>
<TR VALIGN="TOP">
<TD WIDTH="10%"> </TD>
<TD>
<hr>
<div align="center">
<table cellpadding="4" cellspacing="0">
<tr>
<td>
<div align="left"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a></div>
</td>
<td>
<table border="3" align="center" cellpadding="6" cellspacing="3">
<tr>
<td>
<div align="center"><font size="-1"><a href="../../elib/index.html">ELib</a>
<a href="../index.html">E Language</a>
<a href="../../smart-contracts/index.html">Smart
Contracts</a> <a href="../../related.html">Related</a>
</font></div>
</td>
</tr>
<tr>
<td>
<div align="center"><font size="-1"><a href="../../download/index.html">Download</a>
<a href="http://rosebud.mumble.net:8888/jar/e/faq.html">FAQ</a>
<a href="../../javadoc/index.html">API</a>
<a href="http://www.eros-os.org/pipermail/e-lang/">Mail
Archive</a> <a href="../../donate.html">Donate</a></font></div>
</td>
</tr>
</table>
</td>
</tr>
</table>
<table width="100%" border="0" cellspacing="0" cellpadding="4">
<tr>
<td><i><a href="mailto:webmaster@erights.org">webmaster@erights.org</a></i>
<br>
or <a href="https://bugs.sieve.net/bugs/?func=addbug&group_id=16380"><i>report
bug</i></a><br>
or <a href="http://www.blindpay.com/crit-me-now.cgi"><img src="../../images/cmn.gif" width="98" height="21" border="0" align="middle" alt="Annotate this page"></a>
</td>
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../images/ribbon.gif" width="18" height="30"
alt="Blue Ribbon Campaign" border="0"></a><br>
<a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
</div>
</td>
</tr>
</table>
</div>
</TD>
<TD WIDTH="10%" valign="bottom"> </TD>
</TR>
</TABLE>
</BODY>
<!-- #EndTemplate --></HTML>