Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!tellab5!toth
From: toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.)
Newsgroups: comp.sys.apple
Subject: Re: P-Systems (was Re: Computer languages on the various Apple Corp
Summary: BASIC is the way it is for a Reason. They are NOT interchangable
	 Lets put it all in context
Message-ID: <1370@tellab5.tellabs.CHI.IL.US>
Date: 31 May 89 13:11:34 GMT
References: <8905271756.AA29116@crash.cts.com> <31982@apple.Apple.COM>
Organization: Tellabs, Inc. Lisle, IL
Lines: 55

In article <31982@apple.Apple.COM>, dlyons@Apple.COM (David Lyons) writes:
> In article <8905271756.AA29116@crash.cts.com> pnet01!pro-nsfmat!pro-europa!nelson@nosc.mil writes:
> [...]
> 
> BTW, I don't object to "lumping" P-code systems in with interpreted BASICs.
> While Applesoft BASIC does do more run-time stuff (searching for lines by
> number when you GOTO them and searching for variable entries in a table,
> for example) than the UCSD P-system does, it doesn't *have* to be that way.
> There's no reason an interpreted BASIC couldn't have the RUN command go through
> and pre-compute the location of teach line & the address of each variable &
> store it into the code.  And there's no reason a P-code Pascal couldn't do
> slow searches for variables if it really wanted to.
> 

Maybe you can lump them together, but I can't!!!

The UCSD P-Code specifications require these methods of variable reference
and function entry/jump(goto) operations (good programming practice that
allows reasonable execution speed).

The BASIC programming practices (extensible arrays, indeterminate string
length, etc) almost required the implementation of linked-lists / tables
for variable storage.  The ability to stop execution, modify variable
usage (create an array entry not previously used), and continue execution
screws up any idea of pre computed addresses.  To be able to pre-compute
addresses, BASIC would no longer be PURELY interpretive (programs must be
pre-processed BOFORE each run, and always run from the first line, this
would require the rewrite of the Apple Kermit builde routines, maybe not
a bad idea after all), and there would have to be a method of defining
string lengths for storage (A$ can be 1 char, 10 char ??char in length).

It is apparent that you despise Applesoft BASIC and P-Code systems.
While I despise the BASIC, the reason I don't care for Apple PASCAL and
the hyperC that was posted on the net is that they run under their own
custom DOS, and the reason that I still have no reason to learn FORTH
is that Mad Apple Forth is that darned Utility disk (DD, get it to run
with those utilities stored under ProDOS and you make a good language
implementation GREAT).

The REAL PROBLEM wit the Apple //e //c line is still that;
 A: there are few real High Level languages that run under ProDOS.
 B: those that exist each has a major limitation at some point.
 C: some are poor compilers (Aztec "C", or is it 'C').
 D: there is no method of linking ouptut from any compiler/assembler
    with output from another.

Is the ProDOS HyperC still being investigated.  Release of that compiler
might make the standard // line usable for a general programmer.

If ProDOS HyperC is never going to be available, Apple (Claris??) should
really consider porting the Apple Pascal to a ProDOS environment.
-- 
------------------------------------------------+---------------------
Maybe I shouldn't have done it, sarcasm is so   | Joseph G. Toth Jr.
seldom understood.  Don't FLAME on me, please.  | uunet!tellab5!toth