Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!dlyons
From: dlyons@Apple.COM (David Lyons)
Newsgroups: comp.sys.apple
Subject: Re: P-Systems (was Re: Computer languages on the various Apple Corp
Message-ID: <32104@apple.Apple.COM>
Date: 1 Jun 89 00:18:33 GMT
References: <8905271756.AA29116@crash.cts.com> <31982@apple.Apple.COM> <1370@tellab5.tellabs.CHI.IL.US>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 60

In article <1370@tellab5.tellabs.CHI.IL.US> toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.) writes:
>Maybe you can lump them together, but I can't!!!

I'm not calling the UCSD P-system and Applesoft the same thing; they aren't.
I said that in general I don't see a fundamental difference between a
P-code system and an interpreted BASIC.  Where *is* the difference?

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

Applesoft arrays can't change size during program execution (not without
machine code routines added on to do the work, anyway).  Dynamic allocation
of string space is a separate issue from the method of execution (there's
nothing preventing the existence of something just like Applesoft except with
statically-allocated fixed-length strings).

>                                                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, [...]

Applesoft is *already* not *purely* interpreted.  Reserved words are tokenized,
and there are forward links to the next line that are kept up to date as the
program is edited.

The pre-processing would be a transparent step--something that the RUN command
would do before beginning execution.

There's no reason you'd have to execute from the first line.

>It is apparent that you despise Applesoft BASIC and P-Code systems.

Is it??  I haven't made myself at all clear, then.  I don't despise them at
all.

Interpreters of any sort are neat.  Usually it means sacrificing *some* speed
(not necessarily very much) and gaining a lot of compactness in the code.

The trick is to make sure most execution time is spent *doing* something
instead of figuring out what to do next.  If the instructions in the pseudo-
language are powerful, the speed penalty may not be that large.  (Just like
using the toolbox on the GS:  In many cases it doesn't make a noticable
difference whether you write an application in a high level language or in
assembly language, since the majority of the exeuction time will be spent
*executing* toolbox calls anyway, rather than executing your own code.)

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

 --Dave Lyons, Apple Computer, Inc.          |   DAL Systems
   AppleLink--Apple Edition: DAVE.LYONS      |   P.O. Box 875
   AppleLink--Personal Edition: Dave Lyons   |   Cupertino, CA 95015-0875
   GEnie: D.LYONS2 or DAVE.LYONS         CompuServe: 72177,3233
   Internet/BITNET:  dlyons@apple.com    UUCP:  ...!ames!apple!dlyons

   My opinions are my own, not Apple's.