File: bookvol12.pamphlet

package info (click to toggle)
axiom 20170501-6
  • links: PTS
  • area: main
  • in suites: bullseye
  • size: 1,050,164 kB
  • sloc: javascript: 8,042; lisp: 3,600; makefile: 505; cpp: 223; ansic: 181; sh: 96
file content (288 lines) | stat: -rw-r--r-- 10,236 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
\documentclass[dvipdfmx]{book}
\newcommand{\VolumeName}{Volume 12: Axiom Crystal}
\input{bookheader.tex}
\chapter{Axiom Crystal Design}
\section{Book presentation}
In the book "Science at the Edge" by John Brockman
(ISBN 978-1-4027-5450-0),
in the chapter "The second coming -- A manifesto" by David Gelernter,
David talks about the way we interact with computers. This has some
bearing on the crystal notion.

\subsection{Book spines}
David points out that we currently have a "desktop metaphor" which
allows us to view our computer interactions as though we were moving
things around on a desktop, typically folders and documents. There are
several limitations of this metaphor.

The first is that there is a limited amount of space on the desktop.
He proposes the idea of a landscape where the computer is just a moving
window. This gives much more real estate to hold information.

The lack of desktop space leads to the icon idea to capture a small
representation of a document or folder. There are limitations to how
representative such a tiny image can be of the original. A book spine
is an excellent representation of the contents of a book but a tiny
picture of a folder, not so much.

If I look at this idea in terms of the Crystal concept I can
see two parallels. The first idea (desktop/icon) vs (landscape/book)
is related to the organization of Axiom. There is an ongoing effort
to organize the whole of the system into some small number of books.
The whole system is then somewhat similar to an encyclopedia where
there is a shelf of related information. 

Currently the algebra books are on the order of 5000 pages of raw
material. They will likely grow many times that size as literate
information is added. One website representation would show the
Axiom books as book-spines where the algebra section could be
broken up (visually, not actually) as encyclopedia-like images.
Thus, you would find the algebra "books" from A-C, D-F, etc.

\subsection{Linking information}

A second idea from the book is the limitations of the hierarchical
file system idea. Why does a particular file have to have a name?
Why does a particular file only live in one folder?

For the first question, he comments that if you had 3 dogs it is reasonable
to name them. But if you have 10,000 cows it probably is not. Some
information can be anonymous.

For the second question, he asks why doesn't a folder "grab" the 
information so that a particular file might not reside in multiple
folders. Unix has this idea embodied in links but Windows doesn't
support the idea.

He suggests that it might be reasonable to have the folders be active
so that a particular piece of information, say a travel receipt, might
be "grabbed" by the taxes folder and the travel expense folder.

Crystal's view of this is somewhat different. Information isn't named.
It resides in "the problem" floating in space. The naming of information
is related to the view. 

So if we take a problem in space, say all of your financial information
and wrap a crystal around it we can view it in multiple ways, each of
which represents a "facet". Moving between these views corresponds to
rotating the crystal to view "the problem" through a different facet.

So, in a financial crystal, you might have a taxes facet, a travel
expense facet, an assets facet, a checkbook facet, etc. A travel
receipt from a business trip which was added to "the problem' would
show up in all of these facets in different ways. It is up to the
facet to organize this piece of information into its proper place
based on the intent of the facet.

"The problem" just is. The meaning of the problem, the division of the
problem into parts, the naming of the parts, the organization of the
parts, indeed, the very idea that a problem has parts is a function of
the facet, not a function of the problem.

\chapter{Experiments}
\section{Hide/Show a div element}
Here we demonstrate the ability to hide or show a named div element.
\begin{chunk}{hide/show a div element}
<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <meta http-equiv="Content-Type" content="text/xml" charset="us-ascii"/>
  <style>
   html { color:#000000; }
  </style>
  <script language="JavaScript" type="text/javascript">
   function hideshow(flag) {
     var c = document.getElementById('crystal');
     c.style.display=flag;
   }
  </script>
 </head>
 <body>
it works
  <div id="crystal" style="overflow:hidden;display:none">
   this is visible
  </div>
 </body>
 <hr/>
 <a href="javascript:hideshow('none')">Hide</a>
 <a href="javascript:hideshow('block')">Show</a>
</html>
\end{chunk}
\section{Hide/Show a nested div element}
Now that we can hide or show a div element we demonstrate the ability
to hide or show a nested div element.
\begin{chunk}{hide/show a nested div element}
<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <meta http-equiv="Content-Type" content="text/xml" charset="us-ascii"/>
  <style>
   html { color:#000000; }
  </style>
  <script language="JavaScript" type="text/javascript">
   function showhide(id,flag) {
     var c = document.getElementById(id);
     c.style.display=flag;
   }
   function toggle(id) {
     var c = document.getElementById(id);
     if (c.style.display == 'block') {
       c.style.display='none'
     } else {
       c.style.display='block'
     }
   }
  </script>
 </head>
 <body>
it works
  <div id="crystal" style="overflow:hidden;display:none">
   <a href="javascript:toggle('facet1','block')">
    integrate(sin x,x)
   </a>
   <div id="facet1" style="overflow:hidden;display:none">
    <a href="javascript:showhide('facet1','none')">
    <br/>
     -cos(x)
    </a>
   </div>
  </div>
 </body>
 <hr/>
 <a href="javascript:showhide('crystal','none')">Hide</a>
 <a href="javascript:showhide('crystal','block')">Show</a>
</html>
\end{chunk}
\section{Hide/Show a ring of elements}
Now that we can hide or show a div element we demonstrate the ability
to hide or show a ring of div elements. There are 3 elements in the
ring, 'facet1', 'facet2', and 'facet3'. Each facet can open or close
the associated 'answer' sub-div element.
\begin{chunk}{hide/show a ring of elements}
<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <meta http-equiv="Content-Type" content="text/xml" charset="us-ascii"/>
  <style>
   html { color:#000000; }
  </style>
  <script language="JavaScript" type="text/javascript">
   var circle = ['facet1','facet2','facet3']
   var here = 'facet1';
   var herept = 0;
   function showhide(id,flag) {
     var c = document.getElementById(id);
     c.style.display=flag;
   }
   function toggle(id) {
     var c = document.getElementById(id);
     if (c.style.display == 'block') {
       c.style.display='none'
     } else {
       c.style.display='block'
     }
   }
   /* hide the old, get the next one in the circle, show it */   
   function docircle() {
     var c = document.getElementById(here);
     c.style.display='none'
     if (herept == 2) {
       herept = 0 ;
     } else {
       herept = herept + 1;
     }
     here = circle[herept];
     c = document.getElementById(here);
     c.style.display='block'
   }
  </script>
 </head>
 <body onload="showhide('facet1','block')">
it works
  <div id="facet1" style="overflow:hidden;display:none">
   <a href="javascript:docircle()">
    integrate(cos x,x)
   </a>
   <br/><a href="javascript:toggle('facet1a')">toggle</a>
   <div id="facet1a" style="overflow:hidden;display:none">
    <a href="javascript:showhide('facet1a','none')">
    <br/>
     <pre>
     sin(x)
     </pre>
    </a>
   </div>
  </div>
  <div id="facet2" style="overflow:hidden;display:none">
   <a href="javascript:docircle()">
    integrate(sin x,x)
   </a>
   <br/><a href="javascript:toggle('facet2a')">toggle</a>
   <div id="facet2a" style="overflow:hidden;display:none">
    <a href="javascript:showhide('facet2a','none')">
    <br/>
     <pre>
     -cos(x)
     </pre>
    </a>
   </div>
  </div>
  <div id="facet3" style="overflow:hidden;display:none">
   <a href="javascript:docircle()">
    integrate(tan x,x)
   </a>
   <br/><a href="javascript:toggle('facet3a')">toggle</a>
   <div id="facet3a" style="overflow:hidden;display:none">
    <a href="javascript:showhide('facet3a','none')">
    <br/>
     <pre>
                 2
       log(tan(x) + 1)
       ---------------
               2
     </pre>
    </a>
   </div>
  </div>
 </body>
 <hr/>
</html>
\end{chunk}
\chapter{Other work}
\section{Understanding the Dynamics of Complex Lisp Programs \cite{Loet09}}
{\bf Abstract}: Recent advances in web technologies and the
availability of robust Lisp libraries supporting them have made it
possible to think of new ways of understanding and debugging large
applications. In this paper, we will discuss two basic ideas for
assessing and verifying the behavior of Lisp programs. First, we
propose to use a web browser for graphically displaying debug output
in a similar but more versatile way as the Lisp listener is normally
used to print output traces. And second, we propose a method for
creating HTML visualisations of complex data and control structures
that don't trade in level of detail for readability. We will introduce
GTFL (a Graphical Terminal For Lisp), which we have implemented based
on these two ideas, and discuss its applications.

This paper is of interest, not for its lisp tracing output, but for
its ability to pipeline output to a browser and the technology that
underlies the whole of it.

GTFL \cite{Loet00} uses 
Hunchentoot \cite{Weit06} as a common lisp web server. It uses
CL-WHO \cite{Weit03} as the Lisp/HTML markup language, HT-AJAX \cite{Mars07}
as an AJAX framework. The combination of these tools with GTFL
allows nicely formatted output that the browser can
dynamically layout, expand, and contract.

\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}