SCOUG-Programming Mailing List Archives
Return to [ 03 |
May |
2005 ]
Content Type: text/plain
I'm quite pleased with the contributions recently by Steven,
Greg, and Sheridan. I've been busy with other volunteer
activities and not had the time in particular to review in detail
Sheridan's Python contributions. I hope to do so by the time
of our next meeting if not in this forum as well. I do think we
need to revisit LEX & YACC as well as have a better
understanding between GCC 3.x and 4.x. My impression was
that a new "front end" corresponding to LEX & YACC
functions had been implemented to provide for a wider, if not
universal range, of programming languages on input. Maybe
we can use our next monthly meeting to bring some clarity on
both of these.
The better we understand the subject the more comfortable,
the more likely to engage in its use. If it takes a few
iterations, that's the price of the learning curve.
We've had a new entry to the list on which OS/2 seems behind
the curve. That's with a new cooperative effort on a
"common" IDE, Eclipse (www.eclipse.org). As we issue up the
claims and challenges here, getting strengthened thereby, we
need to remind ourselves of one of our original goals: to find
some way to contribute to open source for OS/2.
Now to return to some more on list processing.
Sheridan has offered a set of examples of lists in Python. At
some point we should go into them into detail, discussing
things like 0- or 1-index origins and whether a slice dimension
should be inclusive or exclusive among others. I know what
choices I would prefer.
I will choose in my examples to use double-linked lists with
each entry having a "previous" and "next" link. Each list has
a double link anchor containing a "first" and "last" entry
address. At some point we will get into list hierarchies where
lists have "child" lists and these in turn have "parent" lists. In
that manner create complex "networks" of lists. But that
comes later.
For the moment let us assume that we implement queues as
lists. We have three types of queues: LIFO, FIFO, and Ordered.
Now nothing prevents us from having these as a data type,
e.g. "dcl fido queue lifo;" or "dcl ralph queue fifo;". Then we
have to decide what "push" and "pop" correspond to.
For a LIFO queue a "push" places the entry at the front of the
queue, while a "pop" retrieves the first entry. For a FIFO
queue a "push" places the entry at the end, while a "pop"
retrieves the first entry. For an ordered queue a "push"
places an entry in proper sequence within the queue, while a
"pop" retrieves the first entry. Thus a "pop" always retrieves
the first entry, while a "push" differs depending upon queue
type.
At some point we will have to decide on the syntax to do the
"push" and "pop". It gets somewhat more complicated "under
the covers" when we share a queue between processes, e.g. a
pipe. All these in due time.
That goes for continuing this thread as well. While I think we
need to have a common understanding of list processing as
implemented in LISP and Python as well as a host of others,
my actual interest lies not so much in its processing as in the
list itself. In particular its ability to store 0, 1, or more entries.
The "assignment" statement which lies at the heart of first,
second, and third generation languages allows a "proof
theory" that holds "one and only one true instance exists".
The "assertion" statement which lies at the heart of fourth
generation languages allows a "proof theory" that holds
"zero, one, or more true instances exist" with zero being
"false". In a sense the assignment statement is a special case
of an assertion.
But a list is a data aggregate along with an array and a
structure. In programming languages such as APL and PL/I,
which support aggregate operands in expressions on the
righthand side of an assignment statement and aggregate
results on the lefthand side, the addition of a list aggregate
allows for an "empty" result, i.e. "false". This comes in
addition to also allowing one or more "true" results instead of
the "just one and only one" of the assignment statement.
What this all means and how it all works out will also become
clear as we gain familiarity with list processing and logic
programming. We should hold off on that while we go back
over territory to which we have had "exposure", but
apparently not "familiarity" within our nervous systems.
I'm speaking here of LEX & YACC and C compilers, what they
can and cannot do. Clarity here as well as the resolution of
claims will resolve lingering doubts impeding acceptance of
larger understandings. So I will put this on hold until we have
cleared the air so to speak.
=====================================================
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 [ 03 |
May |
2005 ]
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.
| 
