[Forwarded by A.Sloman because the mail->news gateway
objected to the To: line]
Date: Wed, 5 Apr 2000 11:28:33 +0100
To: popforum <pop-forum@cs.bham.ac.uk>
From: "Stephen F. K. Leach" <steve@watchfield.com>
Subject: List of Possible Poplog Projects
Hi,
For my own amusement, during a long car journey, I composed a list of
possible collaborative Poplog related projects. I include them here
to see if they spark off any takers - I think they are all worthy
projects. Some are much easier to tackle than others.
For myself, I am able to devote my time to any project that allows
me to use Poplog with web servers, especially to support e-commerce.
My focus of interest is on XML at the moment; for example, my next
posting will be my Embedded XML library (embedded_xml.p) which,
though I say it myself, is just amazing. It justifies the use of
Pop11 all on its own!
The big question in my mind is how best to support collaborative
projects such as these? I am not familiar with DAV but it appears
to be attracting quite a lot of attention.
So, in no sensible or intelligent order whatsoever ....
1. Documentation project
Although Poplog's documentation is actually very fine,
new users have difficulty finding their way around.
The fact that the documentation is only really accessible in
VED is an additional needless barrier.
The documentation project would address this barrier to
adoption by (1) adding FAQLs and How-tos (2) representing the
documentation in HTML and (3) providing superior navigation.
The last point would be provided by better structuring an
overview and by providing search tools with familiar
interfaces - along the lines of Yahoo/Altavista etc.
This project probably requires the support of the CGI
and XML projects below.
2. Internationalization
It appears that Poplog 15.53 is very close to being ready for
Unicode. This project would set a simple-sounding goal such as
delivering a non-English language Poplog with all banners and error
messages output in the correct language. This would probably
require following through the Unicode conversion.
Subsequently, the massive task of internationalising the documentation
could be considered.
3. Integration with open source databases
One of the most persuasive tools in the open source toolbox are
the databases such as PostgreSQL and MySQL. Although Poplog does
come with an ODBC library, this is a very tricky thing to set up.
This project would develop libraries for interfacing to the
best open sources databases. Unlike the close-to-lethal interface
to the X-toolkit, these libraries would aim to deliver an
useful and expressive API.
4. Native d/b
Poplog should also come equipped with its own native database
library. I suggest that this should be modelled on properties
i.e. rather than try to be very general it should be very easy
to see how to use it and follow an already successful model.
The advantages of this would be that it allow developers to
write applications that only require Poplog - and not other
installations. It would also create a database format that
was protected from software rot.
Although I imagine that this would not be a full-featured database
model, it would definitely have to support some level of
locking - so that multiple CGI processes could use it
simultaneously.
[Some people will undoubtedly point out (correctly) that this is
reinventing the wheel. However, I would have paid a lot of
money for such a thing this Christmas. In the end I went through
PostgreSQL, which is a fine open source d/b, and felt the
result was overblown and unsatisfactory.]
5. Native image (file format) import, export, manipulation
Along with a native database model, Poplog also needs the ability
to process images - mainly 2D images. In particular, Poplog should
be able to read and write image files in a wide variety of formats.
Although this has been done by linking with popular libraries written
in C, it is plain that they have not survived as well as Poplog!
The argument for these native implementations is that functions
written in Pop11 twenty years ago are still being used on a daily
basis. So for relatively static structures such as image formats,
the investment is relatively safe.
This project really benefits anyone trying to do e-commerce
applications. If you wanted to do something like Macromedia's
Drumbeat then having this library would eliminate a lot of
the basic work.
A requirement on this project would be the ability to render
text in different formats into image buffers. This might well
require some link-up with the FreeType project, for example.
6. Enhanced properties
One of the most powerful datatypes in Poplog is the property.
This project would add multi-dimensionality. At the moment,
Poplog properties map from 1 item to 1 item. Multi-dimensional
properties would map from M items to N items where M >= 0, &
N >= 0. (And, yes, the zero cases make sense.) Such
multidimensional tables could be enhanced further by providing a
mechanism to specify specialised property entry keys.
The benefits of this project would be immediate for experienced
programmers. No longer would they have to work with tables of
tables (and worry about the space leaks entailed by that
technique, mucking about with -pop_after_gc-), nor would they
have to be concerned about the wastage caused when encoding
1 item -> 2 item properties, nor worry about the encoding of
sets.
One of the requirements of this project would be to generalise
the current set of GC flags "tmparg", "tmpval", "perm" etc to
the M/N case. Since this requires cooperation with the garbage
collector this is actually not as simple it would have appeared.
7. Replacement pointers
We all hate the way built-in datatypes have special properties
that we cannot replicate. A case in point is the way the
Poplog garbage collector can elide chain of Prolog variables.
It is not possible to write a datatype with that property at
present. The unwritten bill of rights for datatypes rules
against this inequality.
This project would introduce a mechanism in Poplog which would
be capable of implementing pointer replacement. The obvious
approach is a hybrid: implement a special type of property (a
replacement property) that the garbage collector uses to replace
on object by another + a way of specifying that a key implements
items that contain replacement pointers.
This idea has plenty of applications. For example, in ObjectClass
the generic procedure is an indirection to the dispatch procedure.
This indirection could be profitably eliminated if replacement
pointers were available. (Actually it would also require the
ability to clobber procedures. That is mentioned later.)
8. Implicit force, explicit delay
Lazy evaluation is a very powerful technique that would be neat to
add to Poplog. Unfortunately, you cannot just go around adding it
indiscriminately. This project would implement a compromise - an
explicit delay with an implicit force. In other words, you could
delay an expression by surrounding it with (say) a funny set of
brackets (e.g. =| .... |= ) but as soon as you try to find out
what it is the expression would be evaluated.
For example, using this mechanism it would have been possible to
implement -pdtolist- without the two-levels of hd vs front, tl vs
back etc.
define pdtolist( procedure p );
=|
lvars it = p();
if it == termin then nil
else conspair( it, pdtolist( p ) )
endif
|=
enddefine;
Unfortunately this wonderful feature does not come without a small
system-wide impact (recognisers need to accommodate delayed expressions).
The goal of this project would be to minimize that cost. [In case
readers are concerned about the relative space costs of this
technique for implementing lists, I hope it is apparent that the
above technique requires 2 long words per deferred object.]
In order to get most benefit from this feature, replacement
pointers should be implemented first.
9. Usable GUI toolkit
The X-toolkit is Poplog's Achilles heel IHMO. This project would
aim to provide a GUI toolkit that was mainly implemented in Pop11
and deriving all the obvious benefits as a result e.g. does not
seg fault, require brain the size of planet to write "hello world",
a reinforced library shelf for the flatulent tomes that
tell you how clever you are for using the X-toolkit etc etc.
I would imagine this project would work bottom-up, defining and
then implementing useful APIs for windowing systems such as X-windows,
and Windows itself, 3-D systems such as OpenGL, and animation systems
such as Quicktime. Once this work had been done, it would then be
a good time to tackle the unification - because only at this stage
would it be clear which APIs had been tackled effectively.
The main benefit of working this way would be that each API would
itself be a valuable piece of work in itself, so the success of this
project would not be all or nothing.
10. Fast maths - calc objects
One of the biggest drawbacks to using Poplog is that high-precision
floating point arithmetic is so slow. This project would implement
"calculator objects". These would be high-performance floating
point calculators, capable of vector arithmetic.
Unlike calculators for people, calculator objects would take
programs as input. These "programs" would be code blocks in which
the usual meanings of variables and arithmetic operators were
specialized for floating point operations.
[To put it another way, you would program these objects in FORTRAN
dressed up to look like Pop11!]
11. Rationalised start-up for UNIX
[My apologies for Windows NT users of Poplog for these two
suggestions. I do not know enough about Windows NT/2k to recast
them into Window-speak. Perhaps someone else can find a unifying
view?]
This project would provide Poplog/Unix with a logical and
familiar set of start up flags. These would include specification
of saved images, libraries to load, subsystem to start in, commands
to execute, paths to search etc. (I actually have a
specification of this should people be interested.)
In particular, these flags would allow both long and short
versions in the GNU style (e.g. --restore <image> and -r <image>).
They would also be chosen so that file-name completion would
work.
12. Rationalised installation (RPM)
Poplog installation is needlessly idiosyncratic. This project would
allow Poplog to be installed either via an RPM or via a configure/make
route. It would ensure that Poplog was installed in a "well-known"
location (which could be modified according to sysadmins wish, as
per Apache).
A requirement for this project would be that it would eliminate
Poplog's dependency on environment variables AND manual editing.
Any meta-knowledge required would be supplied at installation time
either by the operator or, preferably, by autoconfiguration.
[I am alluding to pophost.p - a very useful meta-knowledge feature
that almost never works because Poplog's installation process is
broken.]
13. XML/HTML toolkit
This project would create a toolkit for working with XML and, less
importantly, HTML and XHTML. Since this is such a fast-moving
scene, the project would have to quickly decide which APIs to
chase, I think.
The big decision would be how to differentiate Poplog. One way
of doing this is with cute hacks such as my embedded XML library.
Another would be to use Prolog to implement transformation rules.
(This is really quite tricky.)
14. Server toolkit
One of Poplog's biggest strengths is that it is fantastic for
writing Internet servers. This project would provide extensible
implementations of the most popular protocols - definitely
including HTTP, OpenSSL and FTP - and develop support libraries for
the rest of us in the process. For example, a well developed
crypto library would be very welcome indeed.
One objective for the toolkit would be to make it possible to
develop a server within the interactive compilation environment
of Poplog, without having to exit and restart.
15. CGI toolkit
This project would provide a "lib cgi.p" that would let people
use Poplog for CGI programming. In particular, this project should
make it possible for UNIX people to write #! scripts easily. This
in turn requires support from the rationalised startup project.
16. Shared library packages, Plugins (e.g. GOSPL)
This project would aim to provide support for using multiple
add-on libraries. At the moment, Poplog is geared up for one
local library. Adding additional libraries is straightforward
but messy and unstandardized.
This project would develop a format for add-on libraries and
make it possible to load them over the Internet. It would have
to address security and versioning to make this work well.
17. Crypto toolkit
Both the server toolkit project and plug-ins project would benefit
from an established crypto toolkit. This project would aim to
provide the most useful tools to support these other efforts. In
particular, it would have to be a two-level toolkit. The lower
level would provide non-controversial tools for establishing
identity (e.g. via MD5) and the upper level would provide the
useful tools that require "regionalisation".
18. Parity of API with Java, ECMAScript, Perl, Python
Several other communities based around programming languages have
put together really excellent, full featured APIs. This project
would study the APIs (especially Java and ECMAScript, I suggest)
and ensure that Poplog provided something similar or distinctly
more convenient.
There are several goals here. The first is to make it easier to
for Java (etc) programmers to work in Poplog - and vice versa.
Why make programmers learn multiple APIs if one has been designed
well? Let's make it easy to people to adopt Poplog from at least
one or two of these other communities. The Poplog community is
pluralistic and this would be a logical extension. Another goal
is simply to keep up with the other communities - I think of it
as a way of keeping Poplog up to strength.
19. Improve consistency of syntax with Java, ECMASCript, C family of languages
One of the nice things about C, C++, Java and ECMAScript is their
syntactic consistency. This is a big benefit to those people
unfortunate enough to have to work with those languages (like me).
This project would provide a C syntax for Pop11. This would be
implemented as a separate subsystem. This would have to be adapted
slightly because of the absence of types, but I would imagine
something like this ....
define factorial( n );
if n <= 1 then
1
else
n * factorial( n - 1 )
endif
enddefine
becomes
function factorial( n ) {
return n <= 1 ? 1 : n * factorial( n - 1 );
}
A big question is what to do about the open stack? There
are quite a few possible answers to that question that the project
would have to answer. [My present view would be that this is only
meant to be a more familiar syntax - not a more familiar semantics -
so that the open stack operates as normal. So the above example
could have been equally well-written as
function factorial( n ) { n >= 1 ? 1 : n * factorial( n - 1 ); }
] Other tough questions are: how are list/vector literals to be
written, how do class/method definitions work?, what to do with
private/public/protected/static attributes?, what tokeniser to
use?, etc.
This subsystem would share identifiers with Pop11 - so Pop11
reserved words would be unavailable (not vice versa, though).
20. Empty top-level sections
This project would allow programmers to create new, empty top-level
sections. This would let programmers add new languages to Poplog
and make direct use of the virtual machine.
Well, that was a long car trip. I hope this list provokes a bit
of argument because it took me long enough to write!!
Steve
|