[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
I have been reading (skimming) the recent discussion with interest,
knowing well that anything written by Jonathan or Chris is likely to be
interesting and useful.
However I have a few meta-comments on the discussion.
(a) If the suggestions currently being discussed were implemented, so
much would break both in the system and in user libraries that I think
it is better to think of them as proposals for a new language (spice?),
not proposals for changes to Pop-11, especially as I believe it would be
very difficult to write programs to convert *automatically* all existing
code that depends on the old syntax into the new syntax. (In part that's
because of the power of Pop-11 to use macros and syntax words whose
operation cannot be statically inferred, since they can depend on
previous run-time events.)
(b) [For information only] Pop-11 already has mechanisms for dealing
with two types of representations for characters.
1. There's the standard ASCII representation as an 8-bit integer
as described in HELP ASCII and REF DATA (see line 182ff).
Pop-11 strings by default are packed 8-bit vectors. Word
records include strings as their representation of the
corresponding character sequence.
(See subscrw, word_string, etc. in REF WORDS
2. There are also "display strings", which are used in Ved/Xved
to implement a wider variety of visible formats for characters,
e.g. bold, italic, underlined. These are "dstrings".
These use 24 bit integers where the bottom 8 bits represent ascii
values and the top 8 bits represent the display format.
The other bits are not used yet (I think).
See REF DATA/dstring and REF STRINGS/dstring
[REF STRINGS also mentions vedstrings, which can be used to
associate arbitrary pop-11 items with a location in a string.
(This is used for the very dangerous mechanism that allows a
mouse click or keyboard action in any location in an XVed text
buffer to activate an arbitrary procedure. This should NEVER
happen without a warning being displayed allowing the user to
cancel the operation!
See REF VEDPROCS, REF VEDCOMMS. Search for 'action'
(This generalises the much older "hypertext" mechanism in
Ved described in HELP vedgetsysfile which required an EXPLICIT
"ESC h" keyboard action.))]
(c) My own feeling is that although the recent discussions of syntax for
various types of data-constructing expressions are interesting and
could, if they had occurred around 1970, have led to much better syntax
for the pop family, they are far less important for real users than
other "semantic" issues like the availability of powerful libraries that
extend what you can easily do, the availability of new debugging and
development tools, etc.
For example, the extension of list syntax to allow "^" and "^^" to be
used and permitting matched pairs of percents %....% anywhere within
a list (or vector expression) to switch between quoted and unquoted
items (both introduced by Steve Hardy) made a really big difference to
the ability of non-expert programmers to write bug-free easily
maintainable list processing programs (even if using "^^" in the middle
of a list can often be inefficient).
Likewise the provision of a list pattern matcher in the mid 1970s
(also designed by Steve Hardy) made an even bigger difference to the
ability of many programmers to write list processing programs that were
right first time, especially because segment variables ??<var> could
occur ANYWHERE in the list, which is unusual.
(There was a residual source of bugs due to the fact that the pattern
variables had to be global variables, until I introduced the "!" pattern
prefix a few years ago as an optional extra, to make pattern variables
lexically scoped. This is a downloadable extra, built into
the Birmingham startup.psv.)
When LIB FLAVOURS was first introduced many people found it also made a
huge difference to their ability to produce complex software systems.
But it had many problems due to its poor integration with the pop-11
programming style, and worse, because it allowed method selection to be
based only on ONE method argument (because of the 'message sending'
ideology for method invocation fashionable at the time). However it was
used successfully in a number of projects including commercial projects
I think.
LIB OBJECTCLASS (designed by Steve Leach) for me was a HUGE improvement
and most of the programming I have done in the last 5 years would have
been either impossible or far more difficult without it. (I would have
had to re-invent most of it.) I suspect that many things done in the
early 1990s to build X-based interface tools in poplog (See REF POP_UI)
and also Ved/Xved could have been done much better if objectlass had
existed earlier.
(Steve objects to the current method invocation strategy used in the
latest implementation of objectclass, which was done when Sussex/ISL
took it over. However it is easy to switch back to Steve's preferred
strategy, though that's not properly documented. At some point we should
decide which is best and change the default. I'll then have to change
lots of stuff in RCLIB which works only with the current default!)
Examples of other libraries that make a HUGE difference for particular
types of software development are
John Gibson's socket library (e.g. without this I could not
so easily have written a newsreader/poster package based
on Ved)
The X facilities built into Pop-11 which are actually very
powerful, though very hard to use in their raw state if
you have not read all the X manuals. (This is what made
XVed possible for instance and the Pop_ui tools.)
David Young's LIB popvision, which provides a lot of utilities
(many written in C and linked externally) for image manipulation
and display. Unfortunately the display facilities use colormaps
and therefore still work only with 8 bit X systems, though
Brian Logan has a temporary fix that works for 24 bits, but not
yet 16 bit displays.)
My RCLIB, based on Objectclass and the X facilities now makes it
much easier than ever before to create control panels, multi-
window displays with moving/mouse-selectable objects, sliders,
buttons, dials, scrolling text sub-panels, pop-up menus, etc.
Many student projects here in Birmingham would have been very
much harder without this.
Poprulebase (based on the pattern matcher and other list
mechanisms) and Sim_agent (based on poprulebase and objectclass,
now extended with sim_picagent based on RCLIB for linking
simulations to displays).
Jon Meyer's regular expression matcher for strings
(See REF REGEXP) is potentially very useful but probably
under-used because it was introduced at a time when very few
people had access to new versions of pop-11
(ISL were not able to continue the low prices for academics
previously charged by Sussex.)
I suspect that some more recent tools that I have not fully understood,
e.g. Steve Leach's stuff on XML, and some libraries other people have
developed for dealing with html are potentially very important for real
applications.
See the utilities at www.poplog.org
There are many other things that would be very useful.
E.g. I suspect that if someone were to do the sort of thing David
Young has done for his image-manipulating and neural net C programs,
but in relation to the GNU scientific/maths library then we could have
in pop-11 something comparable to (more powerful than?) the
widely used matlab system.
Moreover Pop11+gsl would be totally free of charge with open source.
For details see
http://sourceware.cygnus.com/gsl
GSL is free. It is distributed under the terms of GPL
It provides a collection of routines for numerical computing, all
written in ANSI C, "to present a modern Applications Programming
Interface (API) for C programmers, while allowing wrappers to be
written for very high level languages."
I assume that would include pop-11!
The reference manual is browsable here:
http://sources.redhat.com/gsl/ref/gsl-ref_toc.html
I counted about 380 entries referring to available
functions, categories of algorithms supported, etc. in the table of
contents.
So writing all the "wrappers" and brief pop-11 documentation would be
quite a big job, though not necessarily a very deep one. The resulting
system could be *enormously* useful for all sorts of interactive
development not now supported in Pop-11 because the poor collection of
mathematical facilities.
By comparison with "semantic" extensions of the above types, I believe
changes to the syntax of existing constructs are really of marginal
importance!
(Though interesting as examples of programming language design issues
for people designing a language from scratch.)
Is anyone interested in forming a collaborative project to provide
the gsl extension to pop-11???
Cheers.
Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (ReadATas@please !)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
|