Macintosh implementations of Poplog or Pop11 
Author Message
 Macintosh implementations of Poplog or Pop11

Does anyone know of any implementation of Poplog (or just Pop11) that
will run on a Macintosh?

--
Alec McKenzie



Sat, 14 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11

I don't know if AlphaPop still works on modern macs I'd rather doubt
it. Robin.



Sat, 14 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11
Hi,


Quote:
>I don't know if AlphaPop still works on modern macs I'd rather doubt
>it. Robin.

Sadly, AlphaPop did not make the transition to the modern memory
management scheme.  I believe (but this may be rubbish) that they
exploited the fact that the old Mac O/S could only address 24-bits
for tagging - and this changed, as it was bound to change, and Cog.
App. had seen too little financial return to continue.

This summer we will see the launch of MacOS X, of course, and this
is a true UNIX.  I am absolutely confident that an impromptu
development team will form to port Poplog for MacOS X.  I have come
perilously close to getting the DP3 (dev preview 3) release for this.
Alas, my spare time is negligible at the moment or I would already be
hacking.

I am not sure how long this port will take since MacOS X is a
POSIX compliant UNIX and (I think) Poplog has been ported to the
PPC architecture already.  I reckon a raw port would be a matter
of a couple of months.  What gets interesting after that is what
to do about VED and X.

MacOS X has the most exciting graphics layer of any popular OS -
Quartz (display PDF), OpenGL, and Quicktime.  X-windows will not
be bundled (hurrah) and totally irrelevant anyway.  XVED is therefore
inappropriate.  So a reimplementation of VED is required.

At this point I get very e{*filter*}d!  Why not implement a new editor
with a proper rich-text model?  How about making it powerful
enough to embed HTML?  How about augmenting Poplog with a full
set of UI building components to make constructing new editors
straightforward?!  I'm definitely up for this!

Steve



Sat, 14 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Quote:
Steve Leach writes:
> ...

> >I don't know if AlphaPop still works on modern macs I'd rather doubt
> >it. Robin.
> Sadly, AlphaPop did not make the transition to the modern memory
> management scheme.  I believe (but this may be rubbish) that they
> exploited the fact that the old Mac O/S could only address 24-bits
> for tagging - and this changed, as it was bound to change, and Cog.
> App. had seen too little financial return to continue.

For those who don't know: Cognitive Applications Ltd ported pop11
to the Mac around 1986 and called it AlphaPop. It won some stunning
reviews (e.g. in Byte) They used it to provide the first multi-media
guide to the National Art Gallery and did similar things for many
other galleries and museums world wide.

Because it was a completely independent implementation (written in
a dialect of C) rather than a port of Poplog, it was not easily
upgraded as poplog pop-11 developed.

E.g. I don't think it ever supported lexically scoped local variables
(lvars). Nevertheless it was very successful and widely used for a
while, though not commercially successful as a product (It might have
been had it arrived just as AI started to boom around 1983-4, and before
there were good common lisp systems for mac.)

For anyone interested in the current state of Cognitive Applications
see:
    www.cogapp.com

They still mention pop-11 in their "services" page.

Steve wrote

Quote:
> This summer we will see the launch of MacOS X, of course, and this
> is a true UNIX.  I am absolutely confident that an impromptu
> development team will form to port Poplog for MacOS X.  I have come
> perilously close to getting the DP3 (dev preview 3) release for this.
> Alas, my spare time is negligible at the moment or I would already be
> hacking.

> I am not sure how long this port will take since MacOS X is a
> POSIX compliant UNIX and (I think) Poplog has been ported to the
> PPC architecture already.

There is a version of Poplog V 15.52 for AIX on PPC (presumably done
by ISL for a customer) at
    ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/new/powaix-15.52.tar.gz
    http://www.cs.bham.ac.uk/research/poplog/new/powaix-15.52.tar.gz

I have no idea when it was done, or for whom it was done or whether
anyone is still using it. I think Anthony Worrall at Reading tried
to bring it up to date but had some difficulty.

Quote:
> I reckon a raw port would be a matter
> of a couple of months.  What gets interesting after that is what
> to do about VED and X.
> MacOS X has the most exciting graphics layer of any popular OS -
> Quartz (display PDF), OpenGL, and Quicktime.

However, if it is proprietary or not available on any other system
we should totally ignore it -- there have been enough of those
monsters!!!!

Quote:
> How about augmenting Poplog with a full
> set of UI building components to make constructing new editors
> straightforward?!  I'm definitely up for this!

Yes. A high priority item for that grant proposal ....

I think Roger Evans once did some design work in that direction,
though I don't know what remains of that.

Perhaps higher priority still is a properly designed, documented and
implemented interface in pop-11/poplog to *any* remote programmable
editor (whether emacs, Ved, Xved, or Steve's new editor, or perhaps even
something like netscape?).

Then you could do your editing on one machine and interface to a
running poplog on another machine or the same machine and the
resource requirements of the application you are deveoping and those
of the editor you are using need not be in conflict -- one
disadvantage of an integrated editor sharing a heap with the
application you are developing, though it has many benefits as
ved/xved users know.

Aaron



Sun, 15 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11
I thought the Mail->News gateway had been fixed, but this message
did not get through. So I am posting it to comp.lang.pop.
Aaron




Subject: Re: Macintosh implementations of Poplog or Pop11
Date: Sat, 29 Apr 2000 14:08:54 +0100

The following may be of historical interest to some people.
And of no interest to others. Decide for yourselves!

Quote:

>>I don't know if AlphaPop still works on modern macs I'd rather doubt
>>it. Robin.

>Sadly, AlphaPop did not make the transition to the modern memory
>management scheme.  I believe (but this may be rubbish) that they
>exploited the fact that the old Mac O/S could only address 24-bits
>for tagging - and this changed, as it was bound to change, and Cog.
>App. had seen too little financial return to continue.

It seemed like a good idea at the time. I know younger viewers will
find this hard to believe, but typical machines of that era had less
than 1 MB of RAM (20 bits needed for the address space). A typical
home computer might have 128K of RAM (only 17 bits). This was in 1986.

We could expect the 24 bit addressing trick to work for at least
another 6 years, even on Macs which were expensive and tended to have
more memory. I.e. until around 1993. This seemed long enough.

Even so, the code was written using macros so that all "tag" and
address manipulations could (and should) be changed to 32 bit
just by redefining the macros, and changing the memory management.

But no one with experience of s/ware dev. would expect it to
really be that simple!

However, if the intended port to the PC had gone ahead, we would
no doubt have found (and eliminated?) all the places where the
24 bit addressing was implicitly assumed in the code: at that
time addressing models on the PC were horrendous. The flat
address space of the Mac was one of the justifications for
developing on it. (And if you don't know what I mean by PC
address models, be very glad! Does anyone else remember "far"
and "near" pointers?)

[Digression: The justifiction for the 6 year prediction:

Memory doubles every 18 months, approx, and had done for
twenty years. And it did continue to do so for the next 14; it still
continues. We might expect the typical home machine in 2001 to have
around 128 MB of RAM. 1 GB of RAM won't be the norm (for a
home machine) until around 2005/2006. Extrapolating backwards,
a typical "home computer" in 1971 should have around 128 bytes
of memory, i.e. 1/8th of a K. This is about right.

Serious hobbyists, of course, have machines a year or two ahead
of the "typical" machine.
]

The tagged address idea was a memory saving compromise, part of
a space/speed trade-off. We wanted to avoid using 12 bytes per
list cell, as is done in poplog and (I believe, but I haven't
looked at the latest version) in Franz Allegro Lisp for PCs.

Space was a very important concern, particularly since there was
no virtual memory.

To see why this is significant, the pop11 database:

  [[felix drinks milk]
   [fido drinks water]] -> database;

would take 96 bytes of list-cell space in poplog, but only 64
bytes at 8 bytes per list-cell, i.e. you could work with 50%
more list data. This mattered.

However, the Macintosh Lisp of around that time (c. 1990) used
a better idea, and (again, if memory serves) only required
8 bytes per list cell, without using tags. The trick is to
use separate areas of memory for list cells versus everything
else. (Actually, if you are going to do that, then you may as
well have separate areas for a few other things as well, such as
storage which cannot contain pointers, e.g. strings.) This would
make memory management (particularly the garbage collector) a
lot more complicated, and there are other costs, but it would
probably have been a better choice.

[Another digression:

Another problem with Alphapop was its speed. Some parts of
it were very fast, but many other parts were slow. This didn't
affect many potential users, but it did matter to a sizeable
proportion of them. There was no single reason why it was slow,
but more a combination of a number of trade-offs.

With hindsight, it is easy to see that in a space/speed trade-off
you should generally go for speed. Because the space problem
solves itself (at a factor of 2 approx every 18 months) and any
speed gains are still a benefit however much faster machines
get.]

Jonathan



Sun, 15 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Jonathan L Cunningham wrote

Quote:
> Subject: Re: Macintosh implementations of Poplog or Pop11
> Date: Sat, 29 Apr 2000 14:08:54 +0100

> The following may be of historical interest to some people.
> And of no interest to others. Decide for yourselves!
> ....
> ...
> The tagged address idea was a memory saving compromise, part of
> a space/speed trade-off. We wanted to avoid using 12 bytes per
> list cell, as is done in poplog and (I believe, but I haven't
> looked at the latest version) in Franz Allegro Lisp for PCs.

> Space was a very important concern, particularly since there was
> no virtual memory.
> ...

> However, the Macintosh Lisp of around that time (c. 1990) used
> a better idea, and (again, if memory serves) only required
> 8 bytes per list cell, without using tags. The trick is to
> use separate areas of memory for list cells versus everything
> else. (Actually, if you are going to do that, then you may as
> well have separate areas for a few other things as well, such as
> storage which cannot contain pointers, e.g. strings.)

More reminiscences:

This method, which involves putting objects of the same type and
size in the same "cage" in the address space, and then all
variable-sized objects (strings, vectors, functions, etc.) in a
separate heap, was also used for a while in the system called
WonderPop (wpop) implemented by Robert Rae (later joined by Allan
Ramsay) in the Edinburgh University AI department, on the
DEC-10 DEC-20 computers. I believe wpop was widely used on
DEC-10 and 20 computers for several years.

I remember using wpop for a few years in the late 70s, via a 1200 bd
connection from Sussex to a time-shared computer in Edinburgh with
about 0.5 MWords memory. Each 36 bit word contained two 18 bit
addresses, so we didn't have 8-bit bytes, etc. The system had many
nice features, including the option of having typed integer or
decimal variables or arrays, and an optimiser which could take
account of the typing. Incrementally compiled wpop on that system
ran as fast as compiled Pascal, on simple arithmetic tasks. I think
wpop was the first pop system with properties (hash tables).

Quote:
> This would
> make memory management (particularly the garbage collector) a
> lot more complicated, and there are other costs, but it would
> probably have been a better choice.

The worst problem I remember with caging was that you had to decide
in advance of starting up wpop how much address space to allocate to
each "cage" (list cells, references, other record classes etc.) and
if you ran out of space in a cage, you had to start again with a
bigger guess.

It was partly experience with that system that led me to argue
against the use of caged memory when we discussed it in the early
days of poplog.

Quote:
> With hindsight, it is easy to see that in a space/speed trade-off
> you should generally go for speed. Because the space problem
> solves itself (at a factor of 2 approx every 18 months) and any
> speed gains are still a benefit however much faster machines
> get.]

Nice argument.

In the early days of poplog there were several issues that arose
about whether to use an implementation that saved space, at the cost
of speed or convenience or simplicity of implementation. We always
argued that memory would become cheaper.

So, for example, we rejected the idea of tagged addresses for lists
which at one time were popular in Lisp implementations. Their
designers then cursed when more addressable memory became available
and they had to use a full word as an address, requiring a major
re-implementation.

Another less obvious point is the large collection of strings for
error messages in the poplog system source files, e.g. things
like this in $popsrc/list_hdtl.p

    mishap(item, 1, if item == [] then 'NON-EMPTY LIST NEEDED'
                    else 'LIST NEEDED' endif)

We discussed moving all those hundreds of strings out into a file,
with numbers or labels and having an error mechanism which found the
appropriate string when an error occurred. We decided against that
on the grounds that it would add significantly to
development/maintenance costs and was inherently seriously
error-prone unless supported by software tools that we were too busy
to consider developing.

There was also the thought that maybe the Virtual memory system
would achieve the same effect anway, if all those system strings
were mainly in pages that mostly remained paged out.

Two further (minor) comments:

(a) the space/speed dimensions may seem to be orthogonal but I
learnt from bitter experience that if I went for speed and that
increased space, it could also cause more paging which then had a
dreadful effect on speed. (I built an index to a database to avoid
linear searches through a long list. The extra size of the index and
its associated procedures triggered paging, so that linear searches
were much faster. Disks were much slower in those days.)

(b) Another dimension which can interact with speed and space is
reliability or robustness which will often be related to simplicity
of design (and therefore maintenance). In general if a gain in space
or speed adds significantly to complexity, or reduces
intelligibility of the code, always think hard before you do it!

Some American Lisp implementations in the late 80s (and maybe later)
also seemed to disregard space issues: they seemed to require far,
far, more memory than the combination of pop-11 and common lisp
needed in Poplog. I never knew why.

Cheers.
Aaron
==



Sun, 15 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11

Quote:

> There is another advantage to removing error messages from the
> source code ... internationalisation.

> In developing a C++ application, modern tools make this relatively
> simple to do. (The strings aren't stored in a file, but in
> a "string table".)

> ...

> This is so obvious, I wonder if it has already been done?

Perhaps not for Poplog, but I remember going to a BCS talk in about 1980
where someone was presenting a big fortran package they had produced,
for the Ordnance Survey I think, which had all the messages in a file so
they could slot in other languages. They'd been doing it for quite a few
years, too. I thought it was an obviously right way to do it then, and
couldn't quite see why the man was making such a big deal of it. It's
easy in Fortran - does C++ buy you anything?

David



Mon, 16 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11
(I've constructed the "To: " line by hand on this one)

Quote:
>> In developing a C++ application, modern tools make this relatively
>> simple to do. (The strings aren't stored in a file, but in

...

David Young (Hi David) said,

Quote:
>...I remember going to a BCS talk in about 1980
(snip)
>couldn't quite see why the man was making such a big deal of it. It's
>easy in Fortran - does C++ buy you anything?

It was the "modern tools" I was referring to, not the language.

In C++ (or C), typically you would have done this by defining the
constant representing the error code; this definition would go in
one file, the usage in the source code, and the actual string
itself in a third place.

E.g. in a file called "errorcodes.h"
    #define E_LIST_NEEDED 32769
    #define E_NON_EMPTY_LIST_NEEDED 32770
Actual usage in the source code, maybe in a file called "foople.cpp"
    mishap((item==NIL ? E_NON_EMPTY_LIST_NEEDED : E_LIST_NEEDED),
            1, item);
and the actual strings themselves need to be entered into the string
table.

Being able to do those three edits with little more than a couple
of mouse-clicks counts, I think, as a yes to "buy you anything?"
(Frex, you never need even to look at the errorcodes.h file,
since the next number in sequence is chosen, and the definition
is constructed and inserted, automagically.)

Of course you could (and I would) define a ved macro to do something
equivalent in poplog; although I wouldn't use integer constants as
the error codes.

The other point to clarify is that the strings are not stored in
a separate file, but as a "resource" which, after linking, forms
part of the executable. This would be on PCs (or Macs). I don't
know about the format of executables on unix nowadays, so I don't
know what the conventions are for embedding data.

There isn't an obvious equivalent for this
in pop11: I suppose it's roughly like making a saved image in
which all the (language specific) error messages have already been
read from the library. It hardly seems necessary.

Jonathan

p.s. Incidentally, anyone comparing this with Aaron's original
message will notice that I reversed the order of arguments
to mishap. This is not an error.



Mon, 16 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11

A more systematic approach to system error handling would have other
benefits. For example my Scheme implementation still has a few
errors that are reported by the POP-11 error-reporting process.
It would be beneficial to be able to plug in my own error messages
in an easy way. Likewise it's sometimes desirable to catch
mishaps and handle them in a non-standard way. For example
one might extend the "+" function to produce a formal sum
"x+y" represented, say, as a prolog term, if addition is given
algebraic arguments.

Robin.



Mon, 16 Sep 2002 03:00:00 GMT  
 Macintosh implementations of Poplog or Pop11

Quote:

> Date: 30 Mar 2000 17:23:31 GMT

> A more systematic approach to system error handling would have other
> benefits. For example my Scheme implementation still has a few
> errors that are reported by the POP-11 error-reporting process.
> It would be beneficial to be able to plug in my own error messages
> in an easy way. Likewise it's sometimes desirable to catch
> mishaps and handle them in a non-standard way. For example
> one might extend the "+" function to produce a formal sum
> "x+y" represented, say, as a prolog term, if addition is given
> algebraic arguments.

You can do this using exitfrom, exitto, catch, throw, and redefining
prmishap, though it can be messy. See HELP CONTROL.

However, I noticed that in HELP NEWS, Apr 22 1996 there's an entry
describing a new exception handling mechanism, which I have never
used:

Apr 22 (John Gibson)
   --- There is now a new mechanism for handling exceptions (mishaps
        and warnings, etc). See REF * EXCEPTION for full details.

        (These changes should be completely transparent to existing
        programs, except in one respect: a redefinition of the procedure
        interrupt that uses the test caller(1) == mishap to determine
        whether it is being called from mishap rather than Ctrl-C will
        no longer work (interrupt is now called from
        sys_exception_handler). However, this test is no longer
        necessary, since a program requiring different behaviour in the
        Ctrl-C case can simply redefine * keyboard_interrupt separately
        from interrupt.)

Anyone who does not have the latest poplog and wants to read the
file referred to can look in

    http://www.cs.bham.ac.uk/research/poplog/doc/popref/exception

(I've removed all Ved's special graphic characters from that file:
the bane of emacs users...). The code is in $popsrc/errors.p

On a very quick scan it looks as if the technique is very like
using catch and throw.

Aaron



Tue, 17 Sep 2002 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Macintosh implementations of Poplog or Pop11

2. RCLIB graphical extensions to pop11 etc in Poplog

3. linux poplog (pop11, prolog, common lisp, ml)

4. graphical extensions to pop11 etc in Poplog

5. RCLIB graphical extensions to pop11 etc in Poplog

6. linux poplog (pop11, prolog, common lisp, ml)

7. graphical extensions to pop11 etc in Poplog

8. RCLIB graphical extensions to pop11 etc in Poplog

9. linux poplog (pop11, prolog, common lisp, ml)

10. graphical extensions to pop11 etc in Poplog

11. PROPEL 0.2+ (pop11 for windows) (pop11 4 windows)

12. Bug in array implementation in linux+PC poplog

 

 
Powered by phpBB® Forum Software