SYSDOC V15                                       Aaron Sloman Dec 8 1990

This contains a mish-mash of stuff with suggestions for V15

At some later stage it should be tidied up, orgnanised into
sections, etc.


         CONTENTS - (Use <ENTER> g to access required sections)

 -- Message from Julian, Dec 7th 1990
 -- Thoughts For POPLOG Version 15 +
 -- 1. COMPILERS/SYSTEM
 -- -- a)  POSIX-compliant binaries.
 -- -- b)  Support for homogenous networks
 -- -- c)  Garbage collection-free operation toolkit.
 -- -- d)  ANDF (Archtecture Neutral Distribution Format)
 -- -- e)  Support for multi-processors/parallel processing
 -- -- f)  POPC support for ML and Clisp.
 -- 2. NEW HOSTS
 -- -- a)  IBM RS/6000
 -- -- b)  ICL DRS 6000
 -- -- c)  Sony NEWS
 -- -- d)  NeXTcube/station
 -- -- e)  OS/2 PCs
 -- -- f)  DG Aviion
 -- -- g)  Ten15 code generator
 -- -- [Aaron: Others? What about:
 -- ---    HP RISC machine. Surely higher priority than Aviion?
 -- ---    803?6 + Unix PCs e.g. AT&T Unix?
 -- ---    MAC II + A/UX ?
 -- ---    Acorn+Mac?
 -- ---    New Operating Systems? Unix SVR4? OSF-1 ??
 -- 3. NEW LANGUAGES
 -- -- a)  SQL
 -- -- b)  C/C++
 -- -- c)  OPS-5 or some sort of production system purely
 -- -- d)  VED support for e.g. FORTRAN, C, Pascal ?
 -- 4. DEBUGGING + UTILITIES
 -- -- a)  Memory managment facilities:
 -- --- 1. Add a new variable, -popmemfree
 -- ---- [Aaron: We also really need a stack of locking points
 -- --- 2. Add a procedure which forces POPLOG to expand to popminmemlim
 -- --- 3. Add a procedure called -sys_size_of
 -- --- 4. Based on how the Explorer GC works on the Mac: Split the heap
 -- --- 5. Add more sys_grbg_list-type procedures for incrementally
 -- -- b)  Symbolic debugging environment. (Compatible with dbxtool ?
 -- -- c)  Profiler to allow an application to be run and then get an
 -- -- d) Improve POPLOG's ability to allow users to generate UIs
 -- --- 1. screen layout tool for VT-type terminals (interface to Curses
 -- --- 2. X-based tools (based on GUIDE or XUI ?), possibly converts
 -- -- e)  Socket utilities
 -- -- f)  Cross-referencer
 -- -- g)  Change "uses/lib" mechanism to avoid spurious identifiers
 -- -- h)  Data display library for taking raw data and displaying it
 -- -- i)  Extensions/changes to POPLOG User Interface ...
 -- --- [Aaron: in particular, easier menu-driven or Emacs-like tailoring
 -- 5. IMPROVED LANGUAGE INTEGRATION
 -- -- a)  Revision of LIB SUBSYSTEM (already started for V14).
 -- -- b)  Consistent convention for swapping between languages
 -- -- c)  Facilities/documentation on converting Pop-11 devices to Lisp
 -- -- d)  Have a poplog.psv containing a (user-definable) subset of
 -- 6. DOCUMENTATION
 -- --- [Aaron: we badly need a printed Pop-11 reference manual]
 -- --- [Aaron: there should be a new edition of the VED user guide]
 -- 7. VED
 -- -- a)  Multiple file views.
 -- -- b)  Fuller EMACS emulation (already started in V14).
 -- -- c)  VED_ENTER command to find out if a particular procedure has
 -- -- d)  Ability to add display attributes to VED buffer
 -- -- e)  Document library to allow automatic section heading, content
 -- 8. POP-11
 -- -- a)  Move towards the POP-9x standard
 -- -- b)  Provide type declaration for Pop-11
 -- -- c)  POP++ - develop from scratch or change Flavours ?
 -- --- [Aaron: Pop version of CLOS?]
 -- -- d)  POP++ browsers etc.
 -- 9. COMMON LISP
 -- -- a)  CLtL2/ANSI (if ready !) conformance.
 -- -- b)  CLOS (rather than PCL i.e. include meta-object protocol).
 -- -- c)  CLX improvements (use xpop rather than external C code).
 -- -- d)  CLIM (Common Lisp Interface Manager).
 -- -- e)  Performance improvements (use of type declarations etc.).
 -- -- f)  Other CLisp PD software (CLM, GINA) ?
 -- -- g)  CLOS browsers.
 -- 10. PROLOG
 -- -- a)  Object-oriented Prolog
 -- -- b)  X access from Prolog
 -- --- [Aaron: what about making DEC-10 syntax the default?]
 -- --- [Aaron: Duplicating the Quintus Prolog library?]
 -- 11. STANDARD ML
 -- -- a)  X access from SML.
 -- 12. EXTERNAL LINKS
 -- -- a)  Direct access to more databases via SQL e.g. Sybase, Ingres,
 -- -- b)  Support for KBMS (apparently the IBM and DEC de facto standard
 -- -- c)  Support for Initiative for Managing Knowledge Assets (IMKA)
 -- -- d)  Callback for Fortran
 -- 13. INTEGRATION OF PROJECT RESULTS INTO POPLOG
 -- -- a)  UIDE
 -- -- b)  LPE
 -- -- c)  TCS
 -- 14. BUG FIXES
 -- DEPENDENCIES
 -- --  a)  Major releases of operating systems.
 -- --  b)  Competitor analysis.
 -- --  c)  Market trends.
 -- ==============END OF JULIAN's MESSAGE===============
 -- Items added by Aaron, previously in Sysdoc V15
 -- 1. Poplog prolog has Edinburgh syntax by default
 -- 2. Complete X11 interface (whatever that means)
 -- 3. Packaged Interfaces to standard X window managers - Xview, Motif?
 -- 4. PWM converted to XPOP (or explicitly abandoned?)
 -- 5. A good collection of facilities for graphics, menus, etc.
 -- 6. A "nice" Xwindow-based default startup package for new users.
 -- 7. CLOS (should we be trying to tailor the implementation
 -- 8. Better Pop-11 debugging aids, including access to lvars in
 -- 9. Generalise ved_sourcefile to cope with all top level declarations
 -- 10. Make ved_sourcefile more easily available for user libraries.
 -- 11. Make all compilers (optionally) record files where things are
 -- 12. A decent expert system building tool for Pop-11 (extend NEWPSYS?)
 -- 13. Extend some of our utilities to work on VMS (e.g. HELP PIPEUTILS)
 -- 14. Sort out how to dealwith XtN string constants.
 -- 15. Check Lisp-based sockets package in ~aarons/popd/socket.lsp
 -- 16. Provide good autoindent facilities in VED.
 -- 17. Scan bugreports for good suggestions
 -- 18. Regular expression matcher for Pop-11 strings and VED
 -- 19. John Gibson's ideas for multiprocessing
 -- 20. Generalise matcher so that "=" can invoke it
 -- 21. Need for host-independent "deliverable" format.
 -- 22. Fix or replace syssaveincr? Various people like it
 -- 23. Find all the things added to V14 that have not yet been
 -- 24. Sort out LIB EXTERNAL, LIB NEWEXTERNAL, C_DEC, NEWC_DEC, etc.
 -- 25. Generalise ved_gbl ved_gel to vectors: gbv,gev,mbv,mev,mcv
 -- Suggestions from Robin Popplestone
 -- 1. More efficient support for continuations and context switching for
 -- 2. More efficient floating point code.
 -- 3. Transparent de-referencing (as in Prolog) would help with persistence
 -- Email from Roger Evans about external.ph etc.
 -- Message from RogerE about XtN
 -- Email from Robd re autoindent
 -- Message from Robin Poplestone Dec 6 1990
 -- -- 1.GC, 2.Continuations, 3.improved floating point code, 4.persistence
 -- Message from RobD about his ideas for a parser generator
 -- Message from Julian Apr 25 1991 about V15 possibilities
 -- Debugging
 -- Appearance
 -- External Links
 -- Programmer Interfaces
 -- Programming Facilities
 -- Enhancements/Changes To Existing Systems

-- Message from Julian, Dec 7th 1990

From julianc@integ.uucp Fri Dec  7 09:58:48 1990
From: Julian Clinton <julianc@integ.uucp>
Date: Fri, 7 Dec 90 09:56:12 GMT
To: aarons, johnw
Subject: POPLOG 15++

Over the past few months, I have been building a wish list for future
versions of POPLOG which I have included here. As you will see, some
features are very vague while otehrs a little more fleshed out. I have
sent copies to Clark, Colin and Karen (and will also pass them onto
Patsie Hughes and John Postoyko shortly). What I asked them to do is
mark the features from 0 (don't bother) to 5 (a must). If they had any
other general wishes they were asked to give a very brief overview on a
different bit of paper.

[Aaron: this scale is not enough. We also need
(a) Effort required (Top priority things that need 20 M/years effort
    are not worth pursuing.)
(b) Whether relevant know-how exists in the Poplog team, or wether it
    would be best done elsewhere.
(c) Which market it will help
    Commercial, academic, Lisp users, Prolog users, Pop users,
    expert system builders, NN designers etc. etc.
(d) Whether it will help future Poplog development.
    (E.g. would it be a useful tool for Poplog programmers.]

(From Julian, continued...)
I was wondering if it would be a good idea to do a similar thing at
Sussex before the board meeting so some basis for discussion could be
established. If you think it is a good idea then could one of you send
this round to appropriate people and collect the responses before the
board meeting. I have not sent this to poplog or xpop since I know how
much time would be wasted.

I look forward to hearing from you.

Julian.
[Items below in square brackets added by Aaron. Also slight reformatting
for ved_indexify, etc.]


-- Thoughts For POPLOG Version 15 +
   --------------------------------

-- 1. COMPILERS/SYSTEM

-- -- a)  POSIX-compliant binaries.

[I have asked Julian to provide information as to what exactly this
means. Without knowing what it is, how much work is involved, etc.
we cannot evaluate this option.]

-- -- b)  Support for homogenous networks
    (e.g. have host-specific directories with appropriate binaries and
    common HELP/TEACH/REF etc. files).

[I think this must mean heterogeneous networks? As far as homogeneous
networks are concerned NFS solves the problem completely on Unix systems
and DEC clusters on VMS, I think. Support for mixed networks, such as
we have a sussex should be offered to users to make it easier for them.]


-- -- c)  Garbage collection-free operation toolkit.
    While they slow things down a little, they stop things coming to a
    complete halt.

[I don't understand what this could possibly be. Does he mean
continuous/incremental garbage collection? That slows everything down
by about 50% on the last count]

    Also extend REF EFFICIENCY to document which procedures are
    guaranteed not to create garbage.

[Might be better to do it the other way round. E.g. there are some
surprising things that can create garbage, e.g. +, /, sysopen (I think),
all VED operations, etc.]


-- -- d)  ANDF (Archtecture Neutral Distribution Format)
    from OSF - Ten15 is one of the contenders.

[Probably impossible. RSRE are willing to fund a CASE studentship
for someone to work on porting Poplog to Ten15. Likely to reveal ways
in which Ten15 can't support Poplog. Rudi Lutz is willing to supervise
such a student. But there's paperwork and recruiting to be done first.]
[However, see my alternative suggestion below.]


{Simon: Interesting and possibly useful, but iff RSRE pays for it.}


-- -- e)  Support for multi-processors/parallel processing
    (kernel level, programmer level e.g. extend PROCESS mechanism ?)


{Simon: This definitely gets my vote!}

[Includes toolkits for making it easier to use sysfork, sysspawn, pipes,
sockets, mailboxes. This could be important]

-- -- f)  POPC support for ML and Clisp.
[I am inclined to think we should abandon this goal. Instead give
people the option to compile a saved image in a reduced Pop11 image
(e.g. omitting VED) then cancel unwanted things, then garbage collect,
then create a saved image. e.g. one could cancel the ML or Clisp
compilers, then garbage collect. Extending POPC would be FAR more
work, would seriously increase the maintenance load, and would not
significantly reduce image sizes. The only advantage would be the
facility to deliver object modules and avoid saved images. I don't
think we have a big enough team to be able to compete with Allegro,
Lucid, NJML, etc. etc.]


{Simon: Although difficult, I'm inclined to say that all the Poplog
languages should be made to work with POPC. Being able to deliver
mixed-language stand-alone object modules is a pretty unique feature,
and one which emphasises that Poplog is suitable for serious,
professional use in industry and commerce. I'm not minimising the amount
of work involved, though.}

-- 2. NEW HOSTS
    ------------
-- -- a)  IBM RS/6000
[Yes if someone pays for it. Very high priority?]

-- -- b)  ICL DRS 6000
[Should follow from conversion to SVR4 on Suns, which we'll eventually
have to do.]

-- -- c)  Sony NEWS
[Is this just like MIPS? If so, done already.]

{Simon: Only worth considering if we have effectively done it already}

-- -- d)  NeXTcube/station
[Would need information on how their operating system differs from
existing Poplog host OSs. Also needs market analysis. It's a very
nice system, but how many people are actually buying it? Low
priority I suspect.]
{Simon: I'm dubious about this, unless there's minimal work to be done}

-- -- e)  OS/2 PCs
[Can't comment without detailed technical description of OS/2 and
market analysys]

{Simon: I thought users were either sticking to MS/DOS, possibly enhanced
to accept extended memory, or switching to UNIX?}

-- -- f)  DG Aviion
[Ditto. This uses M88000. Probably low priority. I won't be surprised if
it dies. Motorola brought the processor out too late.]

{Simon: Not worth bothering}

-- -- g)  Ten15 code generator
[Only if funded by RSRE. Will probably require Ten15 (TDF) to be
extended.]

-- -- [Aaron: Others? What about:
-- ---    HP RISC machine. Surely higher priority than Aviion?
{Simon: If it wasn't for our friends at HP I don't believe we'd even
consider this}


-- ---    803?6 + Unix PCs e.g. AT&T Unix?
-- ---    MAC II + A/UX ?
-- ---    Acorn+Mac?
    Acorn recently struck a deal with some important American
    computer manufacturer. (Apple???)

-- ---    New Operating Systems? Unix SVR4? OSF-1 ??

{Simon: We'll probably have to a SVR4 port at sometime, although it's
not clear what this entails: I thought it effectively contained BSD as a
subset, so we could link Poplog against BSD compatibility libraries (or
whatever) with little problem?
The Ultrix kernel will at some point be rewritten, based on the OSF-1
kernel. So we'll have to think about OSF-1 then. However, I guess most
manufacturers who moved to OSF-1-based UNIXes will ensure that their new
products are compatible with their predecessors}

-- 3. NEW LANGUAGES
   ----------------
-- -- a)  SQL
-- -- b)  C/C++
-- -- c)  OPS-5 or some sort of production system purely

[Purely what??? OPS-5 already runs in Poplog CL. Tom used to use
it for teaching here. LIB NEWPSYS could be extended to provide
(a) an interface to a database based on FLAVOURS
(b) an Object oriented extension to the Poplog database (much easier?)
(c) hooks to Xpop for menus and tracing.]


-- -- d)  VED support for e.g. FORTRAN, C, Pascal ?
    (some available for free/small fee already)


-- 4. DEBUGGING + UTILITIES
   ------------------------
-- -- a)  Memory managment facilities:

-- --- 1. Add a new variable, -popmemfree-
    giving the amount of free space left in the heap (so user can tell
    if a GC is likely).

[Already strongly, requested by Steve Knight and others. Would be an
active variable.]

-- ---- [Aaron: We also really need a stack of locking points
in the heap, so that instead of only sys_lock_heap and sys_unlock_heap
you can unlock a _portion_ of the locked heap. This might be used to
make GC's quicker
in VED, for instance.]


-- --- 2. Add a procedure which forces POPLOG to expand to popminmemlim
    (currently only expands to this when more space is needed e.g. needs
    to be forced with something like initv).

-- --- 3. Add a procedure called -sys_size_of-
    which returns the amount of heap used by a particular structure
    (should it be recursive e.g. follow pointers ?).
[what's wrong with -datasize- ?]

-- --- 4. Based on how the Explorer GC works on the Mac: Split the heap
    into sections. Use section 1 in the same way as the POPLOG heap is
    used at the moment but make it smaller. During garbage collection,
    copy tagged objects into section 2. When section 2 eventually
    becomes full, garbage collect that section and copy referenced
    objects into section 3 etc. This takes advantage of the fact that
    the most recently created objects are the most likely to be garbage
    collectable. This means that GCs should have a high free-up rate for
    the time spent doing them and each should should take a short amount
    of time. Apparently the size of sections increases i.e. section 3 is
    bigger than section 2 is bigger than section 1 etc. (there is
    probably some technical name for this but I don't know what it is).

[Sounds like "generational" garbage collection. Also in Allegro CL.
This description can't be quite right: all referenced objects would
always be copied to the next section, leaving previous sections
empty. Also there must be a time when the whole thing re-starts. When?]

{Simon: Surely it's not worth even considering making drastic changes to
the garbage collector without an indication of likely benefits? Much is
claimed for generational GC, but one cannot say a priori that it would
be of benefit to Poplog. After all, the Poplog GC is exceptionally good.
Remember that garbage collectors are tailored to the requirements
of particular source languages (i.e., the semantics of a language
dictates the design of its storage manager). So what's good for one
system might not be good for Poplog}.


-- --- 5. Add more sys_grbg_list-type procedures for incrementally
    reclaiming store.

[Strongly requested by Steve Knight. I think this is probably very
important for sophisticated programmers who want to minimise GCs.
It could be used by VED also. On the other hand, POPC would let
super-sophisticated programmers do it them selves....]

-- -- b)  Symbolic debugging environment. (Compatible with dbxtool ?
    Look+feel problems ?). Changeable key mappings etc. Include ability
    to single step, find values of variables (including lvars), run to a
    proc, step into proc, step over proc etc. Character terminal and X
    versions.

[We MUST try to find what sophisticated Lisp users who _reject_ poplog
actually want, and then implement it for Poplog Lisp. Similarly
Prolog. Then try to copy as much as possible of the Lisp debugging tools
for Pop11. Who will do the investigation of what Lisp users want?
Probably needs co-operation from customers who consider Poplog Lisp
then reject it.]

{Simon: Source-level debugging is very important. I think we can guess
what Lisp users want: breakpoints, single-stepping, source-code displays
and run-time lvar access. This same things are useful for POP-11 and ML
to some extent. The debugging requirements of Prolog are quite different
however: what is initially required is 1) a 5th port (Unify) and 2) the
ability to say something like: "spy Pred at Port if the call to Pred
matches Term". 2) can be done as an extension of the current spy
mechanism (in fact, we have an experimental version of something
like this). 1) requires a substantial revision of the spy mechanism.}



-- -- c)  Profiler to allow an application to be run and then get an
    execution profile displayed/printed (e.g. for time spent in
    different procedures, number of times a procedure is called etc.).
[Yes including John Williams hi-res profiler, which I had hoped would
be ready for V14 but apparently isn't quite.]

-- -- d) Improve POPLOG's ability to allow users to generate UIs
    (user interfaces) quickly in a uniform manner on all hosts:
[This is all UIDE stuff?]

-- --- 1. screen layout tool for VT-type terminals (interface to Curses
    in UNIX)

-- --- 2. X-based tools (based on GUIDE or XUI ?), possibly converts
    GUIDE output into Pop-11 code (early UIDE deliverable ?).


-- -- e)  Socket utilities
[I am amazed that users have not been screaming for this, considering
what it would make possible/easier. What's the VMS equivalent?]

-- -- f)  Cross-referencer
[For all four languages? We should be able to import them for other
languages, e.g. Edinburgh prolog toolkit includes one. However, people
keep extending the syntax of Pop-11, making anything that depends in
knowledge of Pop-11 syntax obsolete. (E.g. I think it's a great pity
that the "defclass" syntax wasn't geared to making it easy to mark and
load in VED instead of mimicking C.)]


-- -- g)  Change "uses/lib" mechanism to avoid spurious identifiers
    Many libraries have at the end of them something like:

        global constant xt_event = true;

    to make uses work properly. Given the number of global variables
    this can use, and the names of some of these variables, perhaps we
    should consider an additional mechanism that we can use, which
    doesn't work using global variables. For example:

        true -> popusedtable("xt_event");
[I don't see this as a serious problem, but others may.]

-- -- h)  Data display library for taking raw data and displaying it
    (under X) as scrolling graphs, bar charts, pie charts etc. Should
    allow incremental updates, resizing, rescaling ...
[UIDE will have to support this. David Young has already done a
lot of it.]

-- -- i)  Extensions/changes to POPLOG User Interface ...

-- --- [Aaron: in particular, easier menu-driven or Emacs-like tailoring
    mechanism for VED]


-- 5. IMPROVED LANGUAGE INTEGRATION
   --------------------------------
[Most of these probably can't be evaluated without looking at
more detailed proposals, plus doing market research, analysis of
user problems, etc.]

-- -- a)  Revision of LIB SUBSYSTEM (already started for V14).

-- -- b)  Consistent convention for swapping between languages
    at top-level and within program code.

-- -- c)  Facilities/documentation on converting Pop-11 devices to Lisp
    streams and vice-versa etc.
[Sounds like an important omission, if not there already. Also sounds
very easy?]

-- -- d)  Have a poplog.psv containing a (user-definable) subset of
    sub-systems, libraries etc.

[Also: Make it easier for users to create language saved images
containing site-specific commonly used VED conversions (as at Sussex).
Ie the "mk" files need more options.]

{Simon: These are definitely useful. But I don't understand Aaron's
comment: I think Julian's points are quite clear and I fail to see why
market research should be necessary.}


-- 6. DOCUMENTATION
   ----------------

-- --- [Aaron: we badly need a printed Pop-11 reference manual]

-- --- [Aaron: there should be a new edition of the VED user guide]

-- 7. VED
   ------

-- -- a)  Multiple file views.
[Not possible except as part of a fairly major revision of VED.]

-- -- b)  Fuller EMACS emulation (already started in V14).
[What exactly should be added? E.g. some Emacs users don't want to
swap because they have written Emacs tailoring code. Would we have
to support the Emacs lisp?]

-- -- c)  VED_ENTER command to find out if a particular procedure has
    been mapped to a key (inverse of ved_hk, ved_kh ?).
[Should be possible without too much effort by analysing VED tables.
But could be slow.]

-- -- d)  Ability to add display attributes to VED buffer
    e.g. for highlighting text, potential expansion to WYSIWYG.

[Not possible without major revision to VED's internal representation.
Is this in Robin's Pantechnicon?]

-- -- e)  Document library to allow automatic section heading, content
    pages etc. (extension to LIB RNO ?). Could extend to automatically
    generate/read PostScript files.
[What does "automatic" mean here? We can't compete with things like
FrameMaker. David Hogg has some code for generating PostScript files
from graphics programs. I presume Robin's Pantechnicon generates
PostScript???]

-- 8. POP-11
   ---------
-- -- a)  Move towards the POP-9x standard
    (if certain features have been agreed).

-- -- b)  Provide type declaration for Pop-11
        e.g.:

        lvars a:string, b:decimal;

    This could only be taken into consideration when pop_optimise is
    non-false.

{Simon: very useful, but non-trivial to implement given the structure of
the POP-11 and VM compilers?}

[pop_optimise is obsolete. See REF pop_debugging.]

-- -- c)  POP++ - develop from scratch or change Flavours ?

[I think any serious object oriented language extension to Pop-11
should await the Pop standard, and probably should be designed by
experienced users of OOP. Several people are already working on
this, including Harry Barrow and Steve Knight.]

        define print(a:string);
            pr(a);
        enddefine;

        define print(a:list);
            ppr(a);
        enddefine;

    This could be made quite efficient for built-in POPLOG datatypes.
    Also allow optimisation if used with lvars a:string etc. syntax.

[If done at all this should probably be modelled fairly closely on CLOS,
with generic functions and multi-methods. ("PLOS" = "PopLog Object
System"???]

{Simon: OO extensions would be a Good Thing. I have two (perhaps)
conflicting views on this: 1) I would like to see an OO extension based
on the existing class mechanism; in other words, a smooth, natural
extension to the existing language. 2) On the other hand, it would seem
a good idea to base the OO facilities on an existing, widely accepted
package such as CLOS. On balance, I guess 1) wins.}

-- --- [Aaron: Pop version of CLOS?]

-- -- d)  POP++ browsers etc.
[I suspect there already exist more flavour-based tools than we have
included in V14.]


-- 9. COMMON LISP
   --------------
-- -- a)  CLtL2/ANSI (if ready !) conformance.
[Is anyone working on Poplog Ansi CL yet? This should have very
high priority.]

-- -- b)  CLOS (rather than PCL i.e. include meta-object protocol).
[High priority judging by the number of people who seem to be
wanting CLOS. But is it really being used?

Has anyone looked at efficiency costs of using PCL rather than something
implemented in Poplog?]


-- -- c)  CLX improvements (use xpop rather than external C code).
-- -- d)  CLIM (Common Lisp Interface Manager).
[We cannot discuss this unless someone finds a specification, so
that an analysis of the task can be done.]

-- -- e)  Performance improvements (use of type declarations etc.).
-- -- f)  Other CLisp PD software (CLM, GINA) ?
-- -- g)  CLOS browsers.

-- 10. PROLOG
   ----------

-- -- a)  Object-oriented Prolog
[What's wrong with FLEX?]

{Simon: I'm not sure that FLEX is really what is wanted. I don't know
much about it, but I think it's much more general than an OO extension
to Prolog. The object-orientedness comes about through the use of frames
for Knowledge representation. It uses a different syntax from Prolog and
is slow (when viewed merely as an OO extension to Prolog). LPA, who
developed FLEX, also market an OO Prolog, Prolog++, so they presumably
don't think that FLEX is suitable as an OO extension to Prolog.

I would strongly favour a deal with Frank McCabe over his Logic and
Objects system (LOS). This is far more powerful than any other module or
OO extension to Prolog I know of. Moreover, it uses an extension to
normal Prolog syntax and compiles to normal Prolog. Using a translation
method suggested by Warren, I understand that there is now little
performance penalty to using LOS rather than straight Prolog. McCabe
worked on LPE and LOS was going to be used in developing LPE tools. Tom
will know more about the possibility of getting LOS for Poplog Prolog,
i.e, whether McCabe is willing and able to let us use it (maybe license
it?).}

-- -- b)  X access from Prolog
[Probably important. But if there's any informal standard for doing
this we should follow it. I had hoped LPE would deliver the first
version of this, and I can't believe it did NOTHING to help.
($popcontrib already contains a first draft XProlog system produced by
Andreas Schoter)]

{Simon: I've written a library XPW_DRAW which provides a higher level,
more "natural" interface (for Prolog programmers) to the Xprolog drawing
predicates.}


-- --- [Aaron: what about making DEC-10 syntax the default?]

{Simon: I definitely think so!}

-- --- [Aaron: Duplicating the Quintus Prolog library?]
[We once discussed the possibility of adding a library to duplicate
all Quintus facilities. Should this objective be revived? (Previously
we were hoping to co-operate with AI Limited on this. Is that
worth trying again?)]

{Simon: I think a Quintus compatibility library is a good idea}

{Comment from Julian
Date: Tue, 11 Dec 90 11:00:05 GMT
Martine said that their main interest in trying to get POPLOG to provide
some level of Quintus compatability was so they could tempt POPLOG
Prolog users to Quintus (if you're writing code in some specific
dialect, why not develop on the definitive system ?). In many ways, a
BIM library might be more useful (I don't know how compatible BIM and
Quintus are) since our Prolog products would then offer a level of
compatability.

Julian.}


-- 11. STANDARD ML
   ---------------
-- -- a)  X access from SML.
[If there's a standard method adopted for doing this in ML we should
follow it. Otherwise only provide a collection of convenient hooks
from ML to most widely used Xpop facilities. E.g. some package for
making menus,and perhaps lib rc_graphic?]

{Simon: sounds reasonable}

{Simon: Both SML-NJ and Poly-ML provide a compatible set of process
primitives (i.e. threads and pseudo-concurrency). The SML community seem
keen on these facilities and I think they are (de facto at least) now
part of SML. We must provide a compatible process module. It shouldn't
be too difficult to devise a sensible interface to Poplog processes:
we've done it before (some while ago) as an experiment, including
timeslicing.
SML-NJ provides continuations based on those in scheme. This looks like
another facility that will have to be provided by all implementations.
I would also like to do some environmental enhancements to ML: e.g. an
<ENTER> f facility, ML code formatter, etc.}


-- 12. EXTERNAL LINKS
   ------------------

-- -- a)  Direct access to more databases via SQL e.g. Sybase, Ingres,
    Informix ...

[Unlikely to be done at Sussex. Find people who are familiar with
SQL, the databases, etc.]

-- -- b)  Support for KBMS (apparently the IBM and DEC de facto standard
    knowledge base management systems).
[Please obtain a specfication if possible. We can then consider it.]

-- -- c)  Support for Initiative for Managing Knowledge Assets (IMKA) -
    DEC (again) + Ford + other collaboration on accessing KBS
    information in a SQLish way. Implemented using C/C++ and X-windows.
    They appear to be licencing rather than making it open standard.
[Probably no concern of ours, or not to be done at Sussex.]

-- -- d)  Callback for Fortran


-- 13. INTEGRATION OF PROJECT RESULTS INTO POPLOG
   ----------------------------------------------
-- -- a)  UIDE
[UIDE will do what it can, but BMT will have to agree to everything,
and there may have to be royalty arrangement.s]

-- -- b)  LPE
[What results? See above]

-- -- c)  TCS
[Probably should be a separate product, like Poplog-Neural?]


-- 14. BUG FIXES
   -------------

-- DEPENDENCIES
   ------------
-- --  a)  Major releases of operating systems.
-- --  b)  Competitor analysis.
-- --  c)  Market trends.

-----------------------------------------------------------------------
-- ==============END OF JULIAN's MESSAGE===============

-- Items added by Aaron, previously in Sysdoc V15

-- 1. Poplog prolog has Edinburgh syntax by default

-- 2. Complete X11 interface (whatever that means)
    Includes tutorial, help, overview documentation, help for
    linking Motif or OpenWindows facilities, guide to setting up
    user environment (e.g. .xrdb file, etc.)

-- 3. Packaged Interfaces to standard X window managers - Xview, Motif?
        (whatever that means)

-- 4. PWM converted to XPOP (or explicitly abandoned?)

-- 5. A good collection of facilities for graphics, menus, etc.
    (I.e. higher level than Xpop, lower level than UIDE. Stuff
    presupposed by UIDE?)

-- 6. A "nice" Xwindow-based default startup package for new users.
    This requires a LOT of experimentation on different sorts of
    users, trying out draft versions (e.g. JonM's PVI?)

-- 7. CLOS (should we be trying to tailor the implementation
    for greater efficiency?)

-- 8. Better Pop-11 debugging aids, including access to lvars in
        error breaks, single stepping with highlighted source
        code (Robin Popplestone, Simon Nichols, John Williams,
        Jon Meyer, all seem to have started working on this
        relatively independently. Someone needs to put it together)

-- 9. Generalise ved_sourcefile to cope with all top level declarations

-- 10. Make ved_sourcefile more easily available for user libraries.

-- 11. Make all compilers (optionally) record files where things are
    defined.


-- 12. A decent expert system building tool for Pop-11 (extend NEWPSYS?)
    I've only recently realised how bad LIB PSYS and LIB PRODSYS are.
    See previous comments about LIB NEWPSYS

-- 13. Extend some of our utilities to work on VMS (e.g. HELP PIPEUTILS)


-- 14. Sort out how to dealwith XtN string constants.
    (A problem discussed in xpop email)

-- 15. Check Lisp-based sockets package in ~aarons/popd/socket.lsp
    to see if it provides an adequate basis for a Poplog sockets kit,
    for Lisp and for Pop-11 (and other languages?)

-- 16. Provide good autoindent facilities in VED.
    Rob (John) Duncan has started working on this, I think. (Requires an
    extension to VED's variables to include vedautoindent flag for each
    file.)

-- 17. Scan bugreports for good suggestions

-- 18. Regular expression matcher for Pop-11 strings and VED
    (IMPORTANT????)

{Simon: I think VED really does need regular expression search and
replacement.}


-- 19. John Gibson's ideas for multiprocessing
    (Whatever they are - mentioned in a recent email message)


-- 20. Generalise matcher so that "=" can invoke it
    (Includes new "match variable" datatype?)
    (Compare LIB FMATCHES)

{Simon: I'd like an efficient (not more general) matcher that works
on lvars and more data structures than just lists. I'd be happy to
see a matcher that was restricted compared to the current matcher,
providing it was faster.}


-- 21. Need for host-independent "deliverable" format.
    Could this be semi-compiled Poplog VM stuff, that could be read in
    via a special incremental compiler?


-- 22. Fix or replace syssaveincr? Various people like it
    and would like it to work.
    More generally, something more general and efficient than
    LIB DATAFILE is needed for persistent stores. What about a
    "persistent" Prolog database?


-- 23. Find all the things added to V14 that have not yet been
    documented or flagged in HELP NEWS and document them.
    (e.g. REF and HELP entries for syssearchpath are out of date, but
    there are probably many more?)

-- 24. Sort out LIB EXTERNAL, LIB NEWEXTERNAL, C_DEC, NEWC_DEC, etc.
    and documentation

-- 25. Generalise ved_gbl ved_gel to vectors: gbv,gev,mbv,mev,mcv

(Might help to compensate for non-VED-friendliness of new
defclass syntax.)


========================================================

-- Suggestions from Robin Popplestone

-- 1. More efficient support for continuations and context switching for
    procedures/languages not using dlocals.
    (Does this require a new "process" package, where dynamic local
    vars and dlocals are ruled out?)

-- 2. More efficient floating point code.
    (E.g there should be ways of avoiding GC's when doing C-like double
    precision arithmetic, by clever optimisations for re-using store,
    or maybe a free-list for ddecimals?


-- 3. Transparent de-referencing (as in Prolog) would help with persistence
    and support for lazy evaluation. (Or so says Robin) See below.


-- Email from Roger Evans about external.ph etc.

From rogere@cogs.susx.ac.uk Mon Sep  3 17:43:06 1990
From: Roger Evans <rogere>
Date: Mon, 3 Sep 90 16:42:55 GMT
To: aarons
Subject: Re: pop/src/external.ph
Cc: poplog

I suspect a lot of the stuff in this file can disappear now. But I don't
think its very high priority. Is there a place to register post v14
tasks, if so, put it in there.

There's a more general issue about the relation between the stuff I put
into the masters to support the old new extensions to the external
interface, and the stuff JohnG has since put in. Eg the routines in
extern_generic.p which are out of date, though they still work and in
fact provide crucial functionality. John: do you have a view on this
stuff?
[Has this all been dealt with now? Aaron]


-- Message from RogerE about XtN

From rogere@cogs.susx.ac.uk Thu Sep  6 11:49:07 1990
From: Roger Evans <rogere>
Date: Thu, 6 Sep 90 11:48:51 GMT
To: aarons
Subject: Re: XtN... string constants
Cc: xpop

yes the topic of how properly to deal with all these string constants
does need sorting out. But you are right in saying it should wait until
v15.

roger

-- Email from Robd re autoindent
From Aaron Sloman Sat Nov  3 15:28:26 GMT 1990
To: robd
Subject: autoindent
I've just found this old message. Did you ever do anything about it?
Maybe it should be brought up for V15?
Aaron

From robd@psunf.uucp Mon Oct  3 14:19:52 1988
From: Rob Duncan <robd@psunf.uucp>
Date: Mon, 3 Oct 88 14:20:55 BST
To: aarons@psunf.uucp
Subject: Re:  autoindent

A feature which I've always thought lacking in VED is autoindenting. I'm
aware of Chris Slymon's package, but it has flaws: it's POP-11 oriented
(so no use for Prolog/ML/Lisp users); it redefines the key bindings for
escape sequences but not for corresponding function keys (who uses
'\^[)' for -vedlineabove-?); and it's just a local library anyway. I
would have thought that autoindenting was fundamental enough to be
built-in to VED, along the lines of automatic line breaking and
left-margin adjustment. Apart from anything else, an "autoindent" flag
would have to be local to each file, something which isn't easy to do in
a library package.

Robert



-- Message from Robin Poplestone Dec 6 1990
-- -- 1.GC, 2.Continuations, 3.improved floating point code, 4.persistence

From Aaron Sloman Thu Dec  6 07:59:19 GMT 1990
To: poplog,alanm%integ.uucp@cs.qmw.ac.uk,colins%integ.uucp@cs.qmw.ac.uk
Subject: Suggestions from Robin Popplestone for V15 requirements.

My numbering. Points summarised from a recent message from Robin
about what he thinks desirable. Maybe we need to address separately
improvements in efficiency and improvements in functionality.

1. GC changes so that pauses for garbage collection during interaction
with editor (and now window manager) don't cause problems. (I suspect
that either a free list mechanism for strings (and vectors) or a
"generational" GC (using a stack of locked heap points rather than
only one) would help this.


2. Continuations or whatever you want to call them. (Landin's J). These
have always been inefficient in POP because of dlocals. Support for
languages without dlocals but with a requirement for continuations
(Scheme and Prolog) could be much more efficient than it is.

{Simon: continuations are important for SML also. It is certainly true
that continuations can be implemented far more efficiently without
dlocals (because of the need that dlocals impose to run entry/exit code
on swap-in/swap-out).
However, this does not affect Prolog: Robin is confusing the semantics
of continuations in Scheme and SML with the semantics of Poplog Prolog's
continuations. These are implemented using the continuation stack and
have nothing (directly) to do with the process mechanism.
To be sure, if efficient Scheme-style continuations were implemented in
Poplog (i.e., not using the process mechanism), then Prolog could be
re-implemented to use these efficient, general continuations and much
Prolog-specific system stuff could go. There might be many benefits in
doing this.
I'm not sure how you enforce a ban on the simultaneous use of dlocals
and continuations. Perhaps when callcc (or whatever) is invoked, a check
is made that each relevant active procedure has no dlocal code?}


3.  Is there some way we could produce reasonable floating point code?
[Aaron: I think this might require typed identifiers, e.g. type decimal,
type ddecimal, and corresponding typed procedures, if it's towork really
well. Robert Rae did this for Wonderpop and on the DEC-10 it made some
arithmetic programs run as fast as Pascal (DEC-10 pascal may not have
had a good compiler?). However, the optimiser was never fully debugged,
because of its complexity!]

4. Persistence & Laziness - I think that some of the implementation
issues of these language features are in fact related. I see persistence
as a way of doing right all those things that are done somewhat ad-hoc
in POP (like autoloading). And I think that persistent languages are
bound to become very important in the mid-term. Laziness will probably
remain of more academic interest, given that functional programming is
likely not to become dominant.

[Aaron: This is closely related, I think, to a recent request from Steve
Knight for us to fix syssaveincr so that arbitrary structures can be
stored properly. I think JG's view is that it is inherently unfixable?]

{Simon: persistence has many benefits; saved images would disappear,
since one can (incrementally) save compiled procedures and data in the
persistent database. Programs which need to save large amounts of
complex data between sessions (e.g. programs which "learn" or update
their "view" of the world) would certainly benefit. However, it would be
a major task to add persistence to Poplog, to say the least (or indeed,
to retro-fit persistence to any existing system). I don't think it's
worth serious consideration at present. As to laziness, I would have
thought "delay" and "force" primitives would be sufficient. I wouldn't
have thought any general facility for lazy evaluation would be necessary
or desirable. Efficient lazy evaluation is not something that can be
grafted on to an existing system.}

Both persistence and laziness seem facilitated in implementations in
which additional "transparent" de-referencing is expected in the normal
course of events (as in Prolog, where there may be a variable in a
data-structure that is invisible to the user).  If one wanted persistence
to be orthogonal to type in a language like POP, then there would be a
penalty of the sort paid in hd and tl (as opposed to front and back)
for each datastructure access.

[Aaron: would anyone care to estimate typical slow down that this would
cause in structure manipulating programs? 30%]

-- Message from RobD about his ideas for a parser generator

From robd@cogs.susx.ac.uk Thu Apr 25 10:45:12 1991
From: Robert John Duncan <robd>
Date: Thu, 25 Apr 91 10:48:44 +0100
To: julian-clinton
Subject: V15 plans
Cc: aarons, simonn

Something I forgot to mention yesterday -- a parser generator (like
"yacc"). I wrote one a couple of years ago, but it was really only a
toy: too slow for anything except small grammars, and rather
idiosyncratic in its syntax. Since then I've had plenty of opportunity
to plan a serious version, but no time to do it.

It's something that POPLOG ought to have. I believe we claim somewhere
to offer "compiler development tools", but there's nothing beyond the VM
and the itemiser. A good parser generator would fill a huge gap. And its
uses are almost limitless: current examples might include

    * LIB EXTERNAL (for parsing C/Fortran declarations)
    * a command interpreter for the debugger
    * reading config files

and that's ignoring the obvious use for the language subsystems (both
existing and planned). Nor would it be restricted to parsing text: any
situation which can be expressed as a state machine responding to input
of some kind is a candidate.

My current plan includes a procedural as well as a syntactic interface,
so it could in principal be called from all languages.

If it's agreed that this is potentialy useful, I'd like to get on with
it early so that we can actually use it for other V15 work.

Robert

From aarons@cogs.susx.ac.uk Thu Apr 25 11:07:49 1991
From: Aaron Sloman <aarons>
Date: Thu, 25 Apr 91 11:10:09 +0100
To: julian-clinton, robd
Subject: Re:  V15 plans
Cc: aarons, simonn

Sounds an interesting idea to me. Why not try it out on JohnG
also? It's the kind of thing whose relevance to ISL's customers
is going to be hard to assess in advance of doing it. Do you have
any idea how much of your time it would take? If it were going
to occupy you fully for a year, we'd have to think more than twice
about it. If it were only a week or two I'd say yes go ahead
regardless of any potential marketplace evidence. But I expect
it is somewhere in between?
Aaron
PS
An example of a potential rival proposal would be enhancing the
Poplog prolog library to be closer to that of quintus? (I know
you would not enjoy that so much!)

From julianc@integ.uucp Thu Apr 25 19:27:47 1991
From: Julian Clinton <julianc@integ.uucp>
Date: Thu, 25 Apr 91 16:13:02 GMT
To: julian-clinton, robd
Subject: Re:  V15 plans
Cc: aarons, simonn


It sounds like a good idea. I think the main question is how long
will it take ? If it's not a long time (two months or less ? but
depends on what else has to be done) I would say we should go for
it.

Julian

PS I'm glad you mentioned a programmer's interface. Ability to use
all POP-11 facilities from other languages is very important.


-- Message from Julian Apr 25 1991 about V15 possibilities

From julianc@integ.uucp Thu Apr 25 19:28:27 1991
From: Julian Clinton <julianc@integ.uucp>
Date: Thu, 25 Apr 91 19:08:48 GMT
To: aarons, bend, johng,
        robd, simonn
Subject: V15 reqs
Cc: julianc@integ.uucp


All

Please have a look through the list of possible features for POPLOG 15.0
and mark the features according to priority (1 - high, 2 - very useful,
3 - if there is time (some hope)). I hope enough of them are self-
explanatory to be useful. After we have an idea of what people's
priorities are, we can spend more effort investigating the finer points
of what's required.

Julian.

[Numbers below inserted by Aaron]


    POPLOG Version 15.0
    -------------------


-- Debugging ----------------------------------------------------------

    Symbolic Debugging Environment For POP-11                               2
    Symbolic Debugging Environment For Common Lisp                          1
    Symbolic Debugging Environment For Prolog                               2
    Symbolic Debugging Environment For Standard ML                          3
    Profiler                                                                1
    Cross-referencer (For Pop, Prolog, Lisp?)                               2


-- Appearance ---------------------------------------------------------

    Improved Graphical User Interface                                       1

-- External Links -----------------------------------------------------

    Embeddability via POPC                                                  1
    Database Interfaces e.g. Oracle, Ingres, Sybase, Informix,              ?
        Unify, generic SQL subsystem                                        ?
    Sockets/RPC                                                             1
    C++ Interface                                                           ?
    Pascal Interface                                                        3
    Other Packages e.g. PHIGS, GKS, NAG                                     ?
    IMKA  WHAT IS THIS???                                                   ?


-- Programmer Interfaces ----------------------------------------------

    POP-11/Xlib Interface
    Prolog/Xt And Prolog/WidgetSet Interfaces                               1
    Prolog Interfaces To Signals                                            1
    Prolog Interfaces To Processes                                          1
    ML To Xlib Interface
    ML To Process
    Common Lisp Interface Manager
    Parser Generator
    Widget Set-independent Interface Library                                1?
    Common Lisp Interface To Signals                                        2?


-- Programming Facilities ---------------------------------------------

    Simulation Package                                                      ?
    S/W Engineering Support (file locks, newmaster library ?)               1
    UIDE-1 (1.5?)                                                           1
    HIP (graphics, sound, images)                                           1


-- Enhancements/Changes To Existing Systems ---------------------------

    VED
        - text attributes e.g. bold, international character sets etc.
        - multiple marked ranges and buffers
        - regular expressions
        - ability to link pop image without VED                             1

SPELLING corrector


    Improved Memory Management
        - ability to lock and unlock identified areas of heap               1

    Efficiency
        - fast floating point routines                                      1

    POP-11
        - more OOPSiness, extend key class system                           1

    Prolog Enhancements
        - Quintus compatability library                                     1

    Common Lisp Enhancements
        - ANSI/Steele ed. 2 (probably only a partial upgrade)               2?

    I/O
        - rewrite of some I/O routines esp. wrt raw devices               why?
        - compatability routines between Lisp/Pop-11 streams/devices        ?
          (others?)
        - ability to save arbitrary data structures (extend DATAFILE,       1
          SYSSAVEINCR), persistent database
        - encryption/decryption of text files                               3
        - compression/uncompression of text files                           1

    External Load
        - ammendment/re-write to produce single libraries for
          C and Fortran using v14.0 facilities                              1

    Documentation
        - compiler options                                                  1
        - more on external load                                             ?
        - POP-11 ref manual                                                 1!
        - sections for each language                                        2

    Multi-processing Support In POPLOG Kernel                               1

    Multi-architecture Support                                              1

    Contrib
        Common Lisp
            - CLM (Motif interface)
            - GINA (graphical interface designer - uses CLM)




--- $popmaster/sysdoc/v15
--- Copyright University of Sussex 1990. All rights reserved. ----------
