John P Baker
Jul 1, 2006
I started programming in IBM S/360 assembler around 1968, and continue to do so to this day. It is the basis of my employment.
I have been programming in PL/I since the early 1970s, and like it very much.
I have also been programming in COBOL since about the same time frame, but have to say that I am bothered by its wordiness.
Now, all of these languages have their respective places, and I use each when appropriate to the circumstance.
However, neither COBOL nor PL/I provide the functionality I am looking for.
I also know that a lot of people favor C++. I am not one of them. This is not because C++ is a bad language. I just don’t find it suitable to what I wish to accomplish.
For what I wish to accomplish, I feel that the development of a new language is the best approach.
Clearly, you disagree. That is fine. But please don’t tell me that I am wrong.
It is simply a difference of opinion.
I see that you have an approach that you feel is appropriate to accomplish the goals you have set for yourself. That is great. I encourage you to pursue your goals with vigor.
I too have an approach that I feel is appropriate to accomplish the goals I have set for myself. And I will pursue them with equal vigor.
Please realize that you should demonstrate to the ideas expressed by others the same degree of respect that you would hope that they would demonstrate to your ideas.
John P Baker
From: osFree@yahoogroups.com [mailto: osFree@yahoogroups.com ] On Behalf Of Lynn H Maxson
Sent: Saturday, July 01, 2006 19:35
Subject: RE: [osFree] Development Project
I really didn't want to get into this argument, but where did
you ever get the idea that you had any PASCAL language
derivative for the two areas, EXEC CICS and EXEC SQL, you
mentioned that would ever offer more than the current PL/I
or COBOL compilers, more specifically than PL/I. As one who
began with CICS at its announcement in 1965 and remained a
regional specialist in the product through the remainder of my
IBM career and the same with PL/I, Wirth in his wildest dreams
in his language evolution never ever got to that level.
I sit here on my OS/2 workstation. In front of me is the
VisualAge PL /I, VisualAge COBOL, IBM DB2, and CICS for OS/2
icons. Thus having begun with CICS prior to entry of the
command-level interface and in fact having to customize the
TCP (Terminal Control Program) source to make an audio
response device correspond to the customer's use, I don't
know how you expect to make a dent with something as
puerile as a PASCAL clone against legacy programming
languages with a complete variable precision, fixed-point
decimal repertoire, i.e. packed and picture decimal format.
As to direct recognition of the EXEC CICS within the compiler
instead of the preprocessor I would think it offers more as a
possible convenience than as a performance enhancement.
Obviously as CICS is an guest operating system functioning in a
host operating system what consideration have you given to
offering the same level of multi-platform support with your
compiler. I doubt if you have more than one platform in mind.
Otherwise you would not ignore what the pre-processor
option offers in terms of reduced support over the compiler
Then finally EXEC SQL where many of the previous
considerations apply as well you have the situation that SQL is
a fourth generation language which has a two-stage proof
engine. The first stage is a completeness proof which verifies
and optimizes the SQL inquiry with a full syntax and semantic
analysis along with code generation. The second stage is an
exhaustive true/false proof, which "tests" the "assertions" of
the query language, returning zero (false) if no "true"
instances found, otherwise a "list" of one or more true
Now the keyword here is "list". The key performance issue
here is the "one at a time" passing of true instances to the
invoking program which is the curse of all first (actual),
second (symbolic assembly), and third (HLL) generation,
imperative languages: their lack of native list processing
support. There is a reason why LISP has managed to evolve
and remain on top of its game.
So if I was going to define a language which interfaced
"natively" with a relational database manager it would have
native list processing support, receiving and processing the list
of true instances without the stutterstep of "one true instance
at a time" or the other programming "awkwardness" of third
As luck would have it I have defined such a language which I
introduced as part of the Warpicity Proposal at Warpstock 98:
SL/I (Specification Language/One) . It wasn't that difficult to
define due to the fact that three pre-1970 "legacy" languages
(APL, LISP, and PL/I) contained everything and more of all
other programming languages since. So if you take the syntax
and data types of PL/I, the operators of APL, and the list
aggregate of LISP, add the ability of both the assignment
statement of third generation HLLs and the assertion
statement (which accepts list variables on input and output)
of fourth generation HLLs you end up with a single fourth
generation language that incorporates all the language
capabilities of previous generations.
Thus your relational database manager can drop the
performance- draining fluff of the "one true instance at a
time" processing and become a seamless fit within an
Of course I was there when Wirth produce PASCAL as an
academic exercise, when he attempted to overcome its
limitations with MODULA, and then when he went out in a
frensy because by then most were wise to his game by the
time Oberon came along. You are most welcome to pursue a
false prophet and engage in yet another academic exercise. I
will continue to shake my head in disbelief.