[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Apr 5 11:28:33 2000 
Subject:List of Possible Poplog Projects 
From:Stephen F. K. Leach 
Volume-ID:1000405.04 

[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