SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sun, 11 May 2008 20:51:13 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	<scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A fourth try about FORTH (and other things)

Content Type: text/plain

Actually, Greg, you're not far off. You cannot write a declarative language
implementation without using an imperative form. At some point implementing
the "what" of declarative language must translate into the "how" of
imperative whether or not you use PL/I as the intermediary to the lower
level imperative assembly language.

The operators of APL have nothing to do with its strict right to left
expression evaluation. Thus lifting those not already in the PL/I builtin
function lexicon poses no problem, occurring simply as an extension to the
language. As far as I know no incompatibilities exist between the common
operators of the two languages. We do have instances where PL/I offers a
proper subset of its APL partner. Thus you just expand the current PL/I
equivalent to its fuller APL operation.

I don't get involved in standards, IBM, ISO, or others. I'm more familiar
with IBM and thus normally conform to them, specifically with respect to
PL/I. Besides the philosophy of SL/I and open source agree on the
independence of the developer if he so chooses to set his own standard,
follow his own path. SL/I certainly allows that.

PROLOG like SQL, TRILOGY and other declarative languages serve as examples
of logic programming based on the two-stage proof engine. We don't borrow
anything from them.

Perhaps I err in using the term "borrow" when speaking of things like the
list aggregate of LISP. You can certainly write a LISP implementation in
PL/I. It has all the components you need to create lists as well as the
functions on lists. Probably accounts for why you have LISP implementations
written in C. However, in PL/I you have no means of using list aggegates
with operators as you do for array and structure aggregates.

Look at what happens when you imbed a SQL statement, e.g. a query, in an
imperative language. You must test, one, if it accepted the statement;two,
if it did, did it have zero or more results; and, three, if more than zero,
then process each "true" result one at a time. For that reason you cannot
imbed an SQL query within a PL/I expression, which demands that one and only
one "true" result occur or exlse a severe error occurs in the program.

That's the nature of an assignment statement in PL/I or any imperative
language: one and only one "true" result. Logic programming allows results
with zero, one or more "true" instances. You cannot use an assignment
statement for this. Thus you require an additional statement type, the
assertion statement of declarative languages. That allows a list aggregate
in an expression and the result.

Now we have no covered the syntax of this statement nor have we designated
how we will declare a list. Currently we don't. We create them as
something with a structure containing pointers and data which we create and
manipulate dynamically in automatic storage with all the logical correctness
falling onto the developer. We could and do in fact create the standard
list operations in software. We could standardise them as function names of
a set of procedures. We don't need more than PL/I to do that.

You make a point with the BNF. We should make two points. One, BNF is a
declarative language. Two, if you look at IBM's implementation, it involves
a mixture of text and graphics (connecting lines, optional and ordered
sequence selections) with rules for their interpretation. Now SL/I is a
text-only language, so you have to have a text-only interpretation of the
graphics. We will once we have acculturated logic programming within our
comfort zone. I would offer you a PROLOG program which does this, but then
you might say I am borrowing as opposed to offering an example.

BNF, the declarative language, has an imperative interpretation. We have
them in C, in PL/I, in any parser as part of syntax checking. We have no
reason to believe that the same doesn't hold for SL/I.

The question is where do we begin. From the outside in or from the inside
out, from as close to the machine as possible and then upwards from there.
We know we have an interpretive mode. At the lowest level it involves
assembly language. That's what makes FORTH a valuable starting point as a
connection between an HLL and assembly language. Transitioning from that
HLL to ours then insures our understanding of the base.

Keep up the good work.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 11 | May | 2008 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.