Re: Low-level vs. High-level programming (was My First Computer)

[mjmahon@aol.com (Michael J. Mahon)]

M. Pender replied:

>Michael J. Mahon <mjmahon@aol.com> wrote in message
>20030724183549.28226.00000581@mb-m24.aol.com">news:20030724183549.28226.00000581@mb-m24.aol.com...
>> Michael Pender wrote:
>> >
>> >Apple Pascal was a half-baked implementation of the language that offered
>> >very limited system access.  It was a compiled Fortran program that
>> >inherited all of the limitations of the Fortran language, as well as
>those
>> >of Pascal.
>>
>> No.
>>
>> UCSD Pascal was a microcomputer adaptation of Wirth's ETH Zurich
>> portable Pascal implementation (based on P-code).  In the process
>> of adapting it to microcomputers, the biggest problem was memory
>> space, so it is painfully optimized toward saving space at the clear
>> expense of a regular P-code.
>>
>> Later, a FORTRAN implementation was done (in Pascal) which
>> used the same P-code interpreter as Pascal.
>>
>> >For example, a program could not have more than 3 files open at once,
>> >system-wide.
>>
>> Pascal certainly has many limitations as a system programming
>> language (many of which were conscious tradeoffs made to enhance
>> its educational value, in the eyes of its creator).  Limitations like the
>> number of simultaneously open files are not language limitations,
>> but implementation limitations--another consequence of optimizing
>> for very small memory (64KB) systems.
>
>As I said, Apple Pascal was a half-baked implementation that only allowed
>three files open at the same time.  In general, Pascal was a relatively
>powerful programming language 10 years ago.  However, Apple's limited
>implementation left a *lot* to be desired, even for its day.
>
>For example, I mentioned that AP only allowed three "files" to be open at
>the same time.
>- one "file" was needed to gather keyboard input (stdin)
>- a second "file" was needed to write to the monitor or printer (stdout)
>- the third "file" was really the only I/O channel available to a program
>without sacrificing the ability to accept user input from the keyboard or to
>send output to the display (or printer)
>
>Thus, a program that actually interacts with the user could not have more
>than one file open for reading/writing at a time without dynamically
>sacrificing one of the I/O streams.  And if a program crashed without
>reconnecting either of the stdin/stdout streasm you had to reboot to regain
>control of the machine.

I believe you are referring to the three "predeclared files":  OUTPUT,
INPUT, and KEYBOARD.  Pascal also permits user-declared files
up to the limits that the system will support.  This implies that the
limitation you describe does not exist.

Perhaps some stalwart Apple Pascal user can comment?

>That is the standard I/O implementation of ForTran 77 -- which leads me to
>believe (but does not prove) that Apple Pascal was written in Fortran,
>whether or not Apple had a commercial ForTran product in the box at that
>point in time.

I can assure you that it is not written in FORTRAN--in fact quite the
opposite:  Apple FORTRAN is written in Pascal.

Apple Pascal was bootstrapped through the ETH Zurich Pascal
implementation, originally running on the CDC 6400.  When UCSD
Pascal was completed, FORTRAN was implemented on top of the
same P-code interpreter, and the FORTRAN compiler also runs in
the Pascal P-code enviroment.

FORTRAN implementations which I used permitted many additional
files to be defined, though few FORTRAN programs ever used them.

>I stand by my previous statement that Apple Pascal was a half-baked
>implementation.

You are, of course, entitled to your opinion.  ;-)

But another possibility is that it was fully-baked, but to a different
specification than you would prefer.


-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/