[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Apr 8 15:25:32 2000 
Subject:Re: List of Possible Poplog Projects 
From:Jonathan L Cunningham 
Volume-ID:1000408.02 

[Forwarded by A.Sloman because the mail->news gateway
objected to the original To: line]

WARNING: parts of this post are not suitable for the humour
impaired, and may cause irritation (at my prolixity) or offence
(at my use of long words: score one point if you know what
prolixity means, and three points if you know what minacious means).


[This has been a long e-mail, written intermittently over about
three days (I kept getting interrupted). I flirted with the idea
of splitting it into a number of topics, but haven't done so, because
it's still in the spirit of Steve's original post. I do suggest that
further discussion is likely to be more specific, about individual
items in the list, and encourage anyone following up on specific
points to change the subject line. Make separate posts if you
follow-up on more than one point. Specifically, since I started this
post there has been already the beginnings of a discussion on
how the pop11 open stack should be handled in a C-like syntax subsystem
in poplog. That, at least, merits a distinct thread.]

Stephen F. K. Leach <steve@watchfield.com> said
>For my own amusement, during a long car journey, I composed a list of
>possible collaborative Poplog related projects.  I include them here

Since a lot of the items in Stephen's unordered list look quite
interesting, but I can't spare the time to contribute positively,
I decided instead to write some unhelpful, negative comments. Please
take this e-mail in the spirit in which it is written, and apologies
in advance for any sense in it. Any constructive comments are
purely intentional.

>1. Documentation project
>
>     Although Poplog's documentation is actually very fine,
>     new users have difficulty finding their way around.


This sounds a leetle like an oxymoron, n'est pas? If it is
not an oxymoron, and the new users are not morons, then it could
just be that poplog is too Titanic. (Deliberate connotations.)

I suspect that the desire to impress with how wondrous it is,
has frequently tempted documenters to provide too much, not too
little information. I'm minded of previous suggestions of
isolating a "tiny pop" subset - and documenting that. Indeed, I
believe somewhere I have such (on two sides of A4, written by
Mike Sharples?).

There is no single solution. No solution will suit every new user.
Every (category of) user will need a different solution. (Snark
hunters will see the significance of this paragraph.)

>     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.


For point (1), new stuff will always need documenting. Re-documenting
old-stuff just increases the amount of documentation, and makes the
documentation problem worse. Needless to say, this doesn't stop
people (re-)doing it.

If point (3) is not a repetition of (2), then all I can say is
that it has been tried. Many times.

Point (2) is both manageable, could be largely automated, and would
be particularly useful if poplog incorporated a (cut-down?) browser.
See "List of Possible Poplog Projects," items 5, 13, maybe 14, 15, 19.

>     This project probably requires the support of the CGI
>     and XML projects below.


Maybe.

>3. Integration with open source databases


I don't know anything about open source databases. This is
fortunate, otherwise I would have wanted to help with this,
and I can't really spare the time. But see comments to 4.

>4. Native d/b
>
>     Poplog should also come equipped with its own native database
>     library.  I suggest that this should be modelled on properties

There are several different things here:

Relational databases, OODBs, data warehousing and knowledge
repositories. There is also the issue of coping with BLOBs in
a relational model.

With the move towards n-tier architectures, a lot of the issues
overlap with CORBA and the microsoft model (What name do you
want to call it today?)

I really can't see inside your head when you say "a database
format that was protected from software rot" -- I guess you
had something specific in mind, but I don't know what it is.
At one extreme, "persistent properties" generalised a bit (see
item 6) could be nice. At the other extreme, you could get lost
in the vastness of interstellar cyberspace.

>5. Native image (file format) import, export, manipulation

>     be able to read and write image files in a wide variety of formats.


JPEGs, GIF, TIFF, maybe BMP, PICT. What else? AutoCAD? PhotoCD?
Each of those has many sub-formats.

While we're at it, how about MPEGs, AVI, Quicktime too?

I think I have to disagree, simply because of the size of the job. Or,
rather, I think it should be postponed until the poplog empire
has 50,000 employees.

In the meantime, being able to read and write images in a couple of
formats would be nice. I suggest JPEG and GIF, which would also
be enough for simple animations. At the moment, I'm using a shareware
package to create animated GIFs, and it has a time-expiry on it. It's
a real pain to re-install it, because it hides "I've expired" information
somewhere on the hard disk. It may be less effort to figure out how to
pay a shareware fee to an Australian. Maybe if I sent an e-mail,
offering to buy him lots of beer if he is ever in England ... ?

>     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!


I think the solution might be to emulate the kind of "plug-in" API
used by browsers and some other kinds of software, both commercial
and shareware. Presumably these APIs are less of a moving target, and,
if done right, a new version of the plug-ins ought to plug-in without
even changing anything in 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.


Well, the fallacy in the argument seems to be the assumption that image
formats are relatively static. Relative to what? Not on a 20 year
time scale. Ten years ago, I don't think we were all using GIFs and
JPEGs, were we? Maybe in ten years we'll all be using some kind of
fractal encoding?

Or maybe parameterised 3-D models, with well-defined rendering protocols
(think of first-person computer games). Or something else.

That's not to say that (some of) the old formats won't still be used,
but I think we are a long way away from the time there won't be new
formats.

(snip)
>     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.


I think this is a different project: project 5A (or 5B).

>6. Enhanced properties

>
>     One of the most powerful datatypes in Poplog is the property.

Yee-haa! Hash-tables are my favourite data structure

>     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

>
>     The benefits of this project would be immediate for experienced
>     programmers.  No longer would they have to work with tables of

The benefits of this project would be non-existent for experienced
programmers who don't have to work with tables.

Sounds like you've been unfortunate enough to do a lot of lowly
(relational) database munging recently, Steve.

>7. Replacement pointers

(snip)
Not sure about this. Many's the time I wished I had this, and for
the life of me, I can't remember a single convincing example why.

And yes, I know I snipped an example. It left me still unconvinced.
Generic functions need an extra indirection, don't they? Isn't it
just the price we pay? (Except in statically compiled languages.)
And, given the overhead of the dispatch mechanism, does one extra
level of function call (which is simple and fast) matter?

>8. Implicit force, explicit delay


(big snip)
>      In order to get most benefit from this feature, replacement
>      pointers should be implemented first.


Yes. If we are convinced about 8, it does make a convincing argument
for 7.

But I'm not convinced about 8. Dynamic lists, as from -pdtolist-
are clever - a neat idea. They could be implemented using lazy
evaluation, as you suggest. But they aren't, at the moment. This
leads to the ugly duckling difference between -hd- and -front-, -tl-
and -back-.

It is also a beautiful swan distinction between accessing
a list and accessing a pair.

> 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.

Delayed evaluation, as a programming paradigm, may or may not be
interesting. The cost can be minimized down to zero by not
building the mechanism into poplog. It needs a much stronger
argument than being "neat to add".

>9. Usable GUI toolkit

I don't know enough about this subject, and how it is implemented
in poplog, to comment. Will that stop me? Of course not!

>     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.


Um, last time I used poplog, sometime last century, the X-toolkit was
Polog's Achilles "black hole" in the Russian sense. (Explanation on
request, if you don't understand that.)

It was on a project, including the letters "U" and "I", in that order.
And it did build things in pop11. Some Belgian guy did most of the work.
(And, in case some Belgian guy still reads the poplog news group, "Hi
Ben, we all know who you are, really.")

So you must want something else/more?

>     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.

I'd say to skip the 3-D stuff. The dust hasn't settled yet. Will Windows
marry Quicktime, or does he prefer the Direct-3D approach? What about Avi?
What does Lara Croft think about it? Is OpenGL Doomed? Will they Quake
with fear? Can I get VRML to work, after that one glorious time?

There are lots of yukky things about trying to produce a generic API
which works with all the different GUI windowing systems. Apart from the
trivial, like whether the Y coordinate points up or down, there can be
simple things like whether a line-segment includes its start and/or end
point. (It's different on the Mac and under Windows, as I discovered
recently when I was writing some PC code for manipulating Macintosh PICT
files. And if you extend the lines, then "relative move" commands are
out by one pixel. And so on.)

>10. Fast maths - calc objects
(snip)
>     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.

I would like proper typed variables in poplog. Yes, truly.

I've got used to using typed languages, and I no see no advantage
whatever in pop11's untyped variables. (Ditto for lisp, incidentally.)

If there are any advantages, someone remind me. (And the ability to
use a variable without declaring it is a DISadvantage, not an advantage.)

Then you wouldn't need special calc objects. Let's replace 10 by
10A. Typed variables.
10B. More optimisations in the compiler and code-generator.

10A would make a lot more optimisations possible for 10B.

Oh, an afterthought, on re-reading:
Untyped container classes might
have some advantages: you might want to have list manipulation routines
which worked on any list, irrespective of whther it is a list of
integers or a list of strings. So you might want variables of type "list"
rather than "list of integers." So part of 10A would be designing
a nice type system, which was stricter than poplog's "procedures or
anything", but not so strict as, for example, C++. I'm sure there must
be a middle ground between the two extremes.

>13. XML/HTML toolkit
>
>     This project would create a toolkit for working with XML and, less

One day's work, so far.

>     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.

XML isn't really a language (or a moving target?). The problem would
be all the specialised, domain-specific usages of XML. XML lets you
define new tags: what you do with them is up to you. But something
which reads in an XML document as a tree structure, and does all
the various substitutiony things would be useful. (OK, it's more than
one days work -- I lied. But it's still relatively small, compared
with the application-specific stuff.)

>     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.)

So, what are transformation rules? Have I  forgotten, or did I never know?
As you say, "this is such a fast-moving scene" -- they may have added
some stuff since I last read the specification.

I guess there are a lot of other TLA that need to be included here: CSS,
XSL, etc.

>14. Server toolkit

>
>     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.

Sounds good.

>    For example, a well developed
>     crypto library would be very welcome indeed.

I want one!

>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.

Too late, IMHO. CGI is the past. Servlets and server-side scripting
languages are the way to go; or at the very least some kind of server
process, accessed directly from the web-server. (We are talking at
least 3-tier, in that case.)

Argue with me if I'm completely wrong. Maybe I don't understand what
you mean.

>16. Shared library packages, Plugins (e.g. GOSPL)

(snip)
Two different things??

To me, poplog libraries and plugins are two different things.

>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".

If I knew what you were talking about, I'd probably want it.

>18. Parity of API with Java, ECMAScript, Perl, Python

I've not heard of ECMAScript. Is that javascript according to the
ECMA standard? Do (old) browsers accept "ecmascript" as the name
of the scripting language?

What do poplog-ites use as their scripting language in HTML docs?
I'd assumed javascript (in preference to VBscript, which I notice
you don't mention).

The only other language I was aware of for embedded scripts was TCL
(of which I wot not). I thought Perl was more for CGI stuff.
Python barely rings a bell; I think I've heard of it, that's all.

Java is more for writing applets; I don't know of any other languages
in which applets are written, but in my mind applets and embedded
scripts and CGI/bin stuff are three different things.

I don't claim I'm right; I do claim I'm slightly mystified.

(snip)
>
>19. Improve consistency of syntax with Java, ECMASCript, C family of
languages

Er, why?

>     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).

Duh, ok.

>     This project would provide a C syntax for Pop11.  This would be
>     implemented as a separate subsystem.  This would have to be adapted

If it is a separate subsystem, why make it an alternative syntax
for pop11? Instead you could improve semantic consistency with these
other language as well. Expose pop11 as an object, or whatever, e.g.

    pop11.lookup(pat);

could call the -lookup- function for the pop11 -database-.

But otherwise, need it be pop11? The argument in favour of syntactic
consistency is even stronger in favour of semantic consistency. Yes,
of course we don't want to throw the pop11 baby out with the pop11
bathwater, but I'm particularly thinking of the open stack ...

(snip)
>      A big question is what to do about the open stack?  There

Well, this leads me to my suggestion for "Possible Poplog Project 21".

But to follow up on a couple of paragraphs above, the open stack is
most likely the biggest source of confusion for a C/C++/Jav/javascript
programmer, who would expect that
    x = calc(y);
would assign a value to x, but that
    calc(y);
would be legal (called for whatever side-effects it produces) and would
not cause problems. If you make the syntax more what they are used to,
the less the are likely to remember the problems this could cause.

>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.

Ok, and this would be very useful for ...

21. New VM instructions, for non-open-stack argument passing.

The poplog open stack is nice for some things, but causes a huge
number of problems. A significant proportion of errors&bugs are
caused by leaving things on the stack accidentally, particularly
for new users.

It is also a big source of inefficiency and preventor of
optimisations.

I'd like to look at what VM support could be provided for languages
which don't require an open stack.

>Well, that was a long car trip.  I hope this list provokes a bit
>of argument because it took me long enough to write!!

I've said lots of arguable things, I think.

Jonathan