towards a modern programming environment

[Dave Long]

>          For many things, of course, it's hard to better text as a
> source code format, although plain ASCII text is easy to better.  If
> you built a GUI for editing programs, it might be beneficial if new
> data types could describe not only how to convert them to text and how
> to parse expressions representing them, but also how to display a GUI
> to edit them.

Visual Basic does this sort of thing.[0]

Vi (Emacs must have something similar)
has a way to run bits of source through
an external filter.  I use it to put in
correct escaping for string constants
and printf formats; it might be useful
to hack up a filter which would display
a GUI for altering complex constants.
(or at least display a more informative
view of them: the poor man's data lens)

> Indeed, I can't imagine a geometry program as useful as KSEG that
> allocated a small parcel of screen space to each geometric item in a
> sketch; the way they intersect and visually interact in a single
> sketch makes it possible to visualize their interactions.

That seems to be the essence of being
an object: when the relations between
parts are as important as the values
of the parts themselves.

Editing source code is somewhat of the
converse, however.  Twenty years ago,
people were talking about structured
editors, to permit only syntactically
valid mutations.  We seem to prefer to 
edit code in a less structured manner
(as a string of characters) and only
commit to making homomorphic changes
at the level of file saves [1].

That is getting somewhat off topic from
the topic of constant literals, though.[2]

> I'd been pondering an outliner functional programming environment ...
> in which subroutine calls would be expandable out to see the variable
> assignments inside the subroutine; each line of the outline would
> contain a name, a definition, and a current value.  I wasn't sure how
> to display the current value of aggregate data structures, and I
> thought that perhaps you'd need to expand out the outline to
> understand anything useful about them.  But if each object defines its
> own displayValue method, that could be displayed; furthermore, if the
> displayed value is editable, it might provide an alternate and often
> more convenient mechanism for modifying the contents of that value.

Or perhaps multiple alternate and more
convenient mechanisms.  In a typical GUI
app, there are many dialog boxes which
can be used to inspect or change state
for any given selection.

I'm imagining something that's a cross
between a spreadsheet, a bento box, and
an advent calendar.

At the top level, instead of a uniform
grid of cells, there would be a bunch
of boxes displaying high-level values.
One could work with those displays, or
"peek behind the flap", expanding the
outline to deal with the lower-level
values implementing the abstraction.

-Dave

:: :: ::

[0] Guillaume Marceau, "About Visual Basic [Was: Industry versus academia]"
<http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02519.html>

> I am aware of one other feature unique to Vb. Vb has a notion of
> coding-time execution, called "custom controls". This allows the (rather
> rare) competent Vb programmer to write convenient GUIs for the
> non-professional Vb programmer. These GUI are typically used to
> pre-select some of the constant argument to class constructors. For
> instance, in the example above, the bitmap argument the button% class
> constructor is a constant. In Vb, a competent Vb programmer could code a
> bitmapped button control, which would then let the beginner coder select
> its bitmap file using a file-open dialog box. It is at the same time
> convenient and a simple way to ensure that "syncheck.bmp" is not
> misspelled.

(the flip side of this approach being a
wonderful comment by Elliot Hughes:)
> In addition to these ample facilities, there exists a powerful
> configuration tool called gcc.

[1] or at least at the level of the CVS
commit.  One might argue that the level
of chunking has to be fairly high, for
in the case of changing both interface
and implementation multiple files often
will need simultaneous coherent changes
to make semantically valid alterations.

[2] to get a little further off topic,
try to find Landin's ISWIM paper:

Landin, "The Next 700 Programming Languages" CACM 1966
> Most programming languages are partly a way of expressing things
> in terms of other things and partly a basic set of given things.
> The ISWIM (If you See What I Mean) system is a byproduct of an attempt
> to disentangle these two aspects in some current languages.

I think what you are describing is a
method of expanding the basic set of
given things.  In Landin's terms:

> The terminology of "abstract objects" "denoting" and "application"
> is frequently more convenient than that of equivalence relations.
> For example, it suggests another way of characterizing each
> problem-orientation of ISWIM.  We can think of a set of abstract
> objects with a partially defined dyadic "application" operation
> and a monadic "designation" operation that associates a "primitive"
> abstract object with each of some chosen set of names, called the
> "constants" of the special system.

but because an expression without any
variables is effectively a constant,
not only can we "designate" constants
by name, but also by "application" of
a set of constructors to those names,
(things in terms of other things), and
furthermore we can do so with domain
specific GUIs as well as with domain
insensitive text editors.

so when Landin says:

> None of these distinctions are concerned with the use of pidgin English
> rather than pidgin algebra.  Any pidgin algebra can be dressed up as
> pidgin English to please the generals.  Conversely, it is a special
> case of the thesis underlying ISWIM that any pidgin English that has
> so far been implemented can be stripped to pidgin algebra. There is
> nevertheless an important possibility of having languages that are
> heuristic on account of their "appliciative structure" being heuristic.

we realize that we use strings of text
for our pidgin algebras because they're
initial: given any other pidgin algebra
desired, we can find a map (M):

    M :: S <- P, where
	S is (EOF | char * String), and
	P is the desired pidgin

Furthermore, by thinking algebraically
we can explain Landin's "program-point"
construct:

> One interesting observation is that the most recalcitrant uses of
> explicit sequencing appear to be associated with success/failure
> situations and the action needed on failure.

as what we would call a continuation, a
structure which is dual to a constant.

(this duality is clearer in spreadsheets,
where cells hold both values (constants,
as maps 1->X, or computed, as maps X->Y
composed with other cells' values) and
display formats (continuations, as maps
from Y to the terminal object), than it
is in programs, where even the simplest
need many constants but most get by with
only one continuation: exit().)

:: :: ::

In other mid-60's news, I recently ran across
some might-have-been "cult software", the TRAC
language, which serendipitously resulted in a
web trail to a piece by David Ness which also
speaks of software cults.

Kragen Sitaker, "cult software"
<http://lists.canonical.org/pipermail/kragen-tol/2002-April/000703.html>

David Ness, "succinctness is power"
<http://mywebpages.comcast.net/dness/notes/succinct.html>