[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 14 21:57:48 1994 
Subject:Re: Public Domain Pop-11 systems ? 
From:jlc (Jonathan Cunningham) 
Volume-ID:941215.01 

> > >  o  By a Mac and use AlphaPop (again, not free)
          ^^ buy?
> >
> > The last Mac-user that I advised to get AlphaPop told me that he learnt
> > from Cognitive Applications Ltd that it is no longer being sold because
> > it won't run under the latest Mac operating system, and there is no
> > effort available to make it run.
>
> This may well be true of 7.5 (I don't the money to check it out).
> However it still works fine under 7.1 with 32-bit addressing switched
> off.

I wonder exactly what is broken? Is it only the need for 32-bit clean
addressing? With hindsight, using tagged 24bit addresses was a serious
design flaw (I know who the idiot was who made that decision, although
Rudi and Chris should accept some of the blame for not disagreeing with
me :-). The original target was to run in 256K, the target was changed
during development to being that AlphaPop should run on a 1Mb Mac Plus:
which only implies 20bit addresses. Using tagged pointers was intended
to save heap space at run time, but I now know better ways to do that
anyway. And with memory doubling every 18months, 24 bit addressing means
that a maximum life of 4.5 years was built into the product at the
design stage. (I think that 24 bit addressing only allows 8Mb (23 bits
worth) of RAM.)

And Lo! seven years after the product first went on sale, we are told
that it is no longer being sold (although I think it died for all
practical purposes long before now).

Updating AlphaPop to 32 bit addressing would have been a labour of love
(ie not commercially sensible) even a few years ago. Now, with the move
to PowerPC chips, it would make even less sense, because quite a lot
of AlphaPop is processor dependent (anything to do with the calling
stack, plus some stuff written in assembler). It would still be less
work than writing the thing from scratch - and probably less work than
porting Poplog, which looks like an obvious thing to consider.

My own inclination nowadays (for a shareware pop language) would be to
write a pop to C++ translator plus a run-time library to link with the
compiled C++ code (containing the GC, I/O etc.).

The run-time library could include a simple pop VM interpreter for
implementing popval. This approach would give a lot of portability with
decent speed, plus allow incremental development. But I would be
inclined to add some extra syntax to the language to allow good static
type checking (Robin Popplestone was doing this kind of stuff
automatically for pop11 a while back - at least, he mailed popforum
about it). The extra syntax would be optional, but untyped or variable
arguments/results would have a speed penalty since they would have to be
translated to less efficient C++ code.

Perhaps I'll do it over the Christmas period :-). Nano-pop! Hmmm, I was
joking, but a Pico-pop? .... with such a nice name, maybe. A couple of
dozen built-in functions, use your own ascii editor? Maybe. Anyone want
to write a specification? Is the turtle libary essential :-)? How about
OOP? Single inheritance with mono-methods? (Piggy-backed on C++ we could
even have multiple inheritance, but I'm thinking also of what would be
needed for the run-time interpreter).

Jonathan

P.S. Mike Sharples at UoS once identified a subset of pop11 (for
teaching) called (I think) tinypop. Its description fitted on a single
double-sided sheet of A4. Anyone remember it?

P.P.S.
	Picopop (draft spec):
		no sections,
		no macros (not difficult to implement but I think macros are a
			Bad Thing because they change the semantics according to
			order of compilation),
		variable names limited to a maximum of 2147483648 characters
		no exitfrom/exitto/chain etc.
		no lexically scoped free variables in nested procedure
			expressions?? (not sure about this - they are useful)
		complex arithmetic but no bigintegers, no rationals