What license is this code released under?

On Fri, Feb 2, 2018 at 3:24 AM, Bernd Oppolzer <bernd.oppol...@t-online.de>
wrote:

> Because of this topic drift, I'd like to inform you, that I
> recently added strings to my version of the Stanford Pascal compiler,
> which is a descendent of the Wirth Pascal P4 compiler.
>
> My string implementation uses two length fields in front of every string,
> the first being the maxlength field, which tells the maximum length that
> the
> string can hold, and the second one is the actual length, which obviously
> should
> be less or equal to the maxlength. Both length fields are two bytes, like
> in PL/1 varchars,
> so a string can by up to 32767 bytes in length. A string variable defined
> as STRING (20)
> occupies 24 bytes.
>
> When the string is used in an expression or passed to a function or
> returned
> from a function, a different format is used (so that is can be passed over
> the stack).
> A string workarea exists to hold the temporary strings while doing
> complicated
> string expressions like concatenations combined with string function calls
> etc.;
> the used area is freed (by resetting pointers) every now and then to
> prevent
> memory leaks.
>
> The string API look much like that from IBMs Pascal/VS. I am preparing a
> document
> which describes all the technical details about strings in New Stanford
> Pascal.
>
> Regarding the problems mentioned below (file buffer, terminal read on
> reset (input)
> before first writeln), Pascal/VS had functions like TERMIN and TERMOUT,
> which
> modified the file descriptor to handle terminal output correctly. I did
> the same
> and inserted a "terminal" flag into the Pascal FCB, so I could fix this
> problem, too
> (in 2016, already).
>
> The new compiler version (with strings) will be available in the next few
> days,
> you can get informations here:
>
> http://bernd-oppolzer.de/job9.htm
>
> and here:
>
> https://www.facebook.com/StanfordPascal/
>
> The compiler runs on MVS (z/OS, too), CMS (generating 370 machine code
> there),
> and on Windows, Linux, OS/2, MacOS (and probably every other system, that
> has a C compiler);
> on the non-mainframe systems at the moment using a P-Code interpreter.
>
> (The string feature is not yet available for the mainframe version,
> because the new P-Codes are not yet understood by the P-Code to 370
> translator;
> this will probably follow by March 2018).
>
> Kind regards
>
> Bernd
>
>
>
> Am 01.02.2018 um 22:22 schrieb Paul Gilmartin:
>
>> On 2018-02-01, at 08:37:07, Pieter Wiid wrote:
>>
>>> BTW, those "'Pascal' strings" were not in Wirth's specification of
>>> Pascal;
>>> they came later with, e.g. UCSD.
>>>
>>> Too true -- Wirth's Pascal was useless for any real work. Character
>>> arrays only.
>>> UCSD Pascal had strings and async block I/O. Coming from the mainframe, I
>>> really liked that.
>>>
>>>
>> Isn't async block I/O a function of how the runtime library is
>> implemented?
>>
>> A few decades ago, I participated in development and support of a Pascal
>> RTL
>> (and compiler) which had asynchronous BSAM and BPAM I/O, transparent to
>> the
>> application program.
>>
>> Another problem arose from Pascal's file buffer convention.  I judge this
>> a
>> result of Wirth's fixation on the "structured programming" paradigm of its
>> time.  Apparently he wanted to avoid "END=, ERR=" type signal handlers,
>> This seriously impacted interactive programming: the program issued a READ
>> before writing the prompt for it.  This was partly alleviated by "lazy
>> I/O",
>> but the programmer still needed to code in a counterintuitive order.
>>
>> Borland Turbo Pascal did not implement the file buffer, much to the dismay
>> of a colleague with whom I shared a program that relied heavily on that
>> file buffer:
>>
>> "What is this supposed to do?  It doesn't work in Turbo."
>>
>> "I obeyed the IEEE standard.  Turbo doesn't.  Complain to Borland."
>>
>> (But Turbo was pervasive; a de-facto standard.)
>>
>> POSIX shell has a more rational construct, still signal-free in:
>>
>>      while command; ...; read X; do
>>          ...
>>          process record X
>>          ...
>>      done
>>
>> -- gil
>>
>>


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

Reply via email to