SCOUG-Programming Mailing List Archives
Return to [ 23 |
July |
2003 ]
Content Type: text/plain
I remain still somewhat in awe of Ben Archer's APL solution
for the peg solitaire problem. The awe comes, one, from the
effort he expended in the solution and, two, from his method
of solution: its reliance on iteration instead of recursion, his
rotating the matrix to allow for a left/right only scan, and
probably a number of other features that I would discover on
review.
As I said three programming languages--APL, LISP, and
PL/I--encompass everything present in all other
third-generation HLLs. PL/I covers the possible data
elements;APL, the possible operators; and LISP adds the list as
a data aggregate as well as the primitive list operators. All
three use the assignment to store the result of an evaluation.
The only thing missing is the logic programming enhancements.
So Peter can talk about some quest of mine to bring all these
together in a single programming language, but I hope it
obvious that all the pieces exist and only the synthesis of
form, the syntax, remains.
APL like Python is an interpretive language. Unlike Python
APL has no defined operator precedence, choosing instead to
to process in a strict left to right sequence altered only by
expressions in parenthesis. So even if you write a "clever"
APL one-liner and come upon it again some time later, the
process to relive your cleverness remains simple:
incrementally parse it right to left, executing each rightmost
parse in turn until you have included the entire expression.
So if people can't understand an APL one-liner or any APL
expression, they simply need an APL interpreter instead of a
mental one.
At the August meeting we will cover device drivers. In doing
so we will look at the broader issue of "compiling" .com, .exe,
.sys, .dmd, .add, .dll, and whatever other forms of object
modules. Object modules have structures. The structure
consists of a linked list of list, code, and data spaces, some
static, some dynamic, all inherently generable.
If I have time, I will disassemble an OS/2 driver and some small
.exe module. We can look at them structurally to ask
ourselves, "Why can we not process program structures as we
would any other data object?".
=====================================================
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
"rollin@scoug.com".
=====================================================
Return to [ 23 |
July |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
| 
