Thanks to all who have tried to help.
I know (or could probably figure out) how to write my own functions
for these text parsing affordances I am after. What I was looking
for is a simple (built-in) syntax to get info from any chunk
description returned in any string or chunk form. The following
(suggested) syntax would add powerful string and chunk referencing
and query to Rev or any xTalk language:
-- get chunk numbers...
the [charNumber] of char 1 of word 7 of line 3 of myFld
the [wordNumber] of word 3 of line 3 of myFld
the [lineNumber] of char 567 of myFld
the [wordNumber] of char 567 of myFld
the [itemNumber] of word 35 line 3 of myFld
-- get chunk strings...
the [lineSting] of char 3 of word 35 of myFld -- would return the
actual line containing that char (as string)
the [wordString] of char 567 of myFld -- would return the actual word
containing that char (as string)
the [itemString] of word 36 of myFld -- would return the actual item
containing that word (as string)
-- get chunk descriptions (inclusive from this chunk to that chunk)
the [wordChunk] of line 12 of myFld -- would return chunk expression
"word 503 to 524"
the [lineChunk] of char 33 to 300 of myFld -- would return chunk
expression "line 1 to 7"
the [charChunk] of word 567 of myFld -- would return chunk expression
"char 8903 to 9126"
the [itemChunk] of word 567 of myFld -- would return chunk expression
"item 14"
the [lineChunk] of item 12 of myFld -- would return chunk expression
"line 4"
The syntax for all of these functions would be more universal if
written in a more universal grammatical form...
the char[s] of item 3 of myFld [as numbered chars] -- returns "char
56 to 78"
the word[s] of line 3 of myFld [as numbed words] -- returns "word 3
to 7"
the line[s] of char 31 to 45 of myVar [as string] -- returns "3. Do
not steal. [cr] 4. Do not kill"
the item of word 4 of line 6 of myTxt [as chunk in chars] -- returns
"char 35 to 45"
xTalk is generally Turing Complete... meaning, it is usually possible
to write a function that will satisfy any algorithmic goal (from the
given lexicon and executable grammar). However, most of us choose to
use xTalk because it is a high level language, it protects us from
the inhuman repetition and complexity of low level logic and function
libraries. When we are each required to write low level functions
for common requests "Which word contains char 33", we are pulled away
from the higher level tasks at hand (why we are writing the script in
the first place... what it is supposed to do). The kind of mental
and algorithmic and notational gymnastics required to do some of
these human tasks is enough to exclude many of the very same people
xTalk was designed to attract. Worse, even those of us nerdy enough
or motivated enough to wade through the obfuscation have to create
duplicate scripts from duplicate effort. All of this seems
antithetical to the original intent of Bill Atkinson (the father of
HyperTalk) and Alan Kay et al of Xerox Palo Alto Research Center (the
fathers of SmallTalk).
I am always amazed by the elegant intent of the original creators of
HyperCard and how obvious this intent infused every nuance of its
original implementation. Later renditions have added features and
have been laboriously held in lockstep with the quicksilver backdrop
of ever evolving OS and hardware combinations and the network that
has more and more dominance over modern computing. However, much has
been lost or forgotten along the way. Much of the egalitarian intent
behind the sentiment behind simple statements like "computing for the
rest of us". Much of this populist intent has slowly eroded along
the way. I would hope that we all continue to respect Bill's
original intent by remembering and honoring the elegance and
egalitarian humanity of his work. This respect should go beyond
simple romanticism. It should guide our purchasing decisions and our
expectations afterwards. Most humans are Turing Complete... given
enough time most of us could write any function in most any
language... but that really doesn't get us much closer to our larger
goals (unless of course we are making a living learning how to become
better and better algorithm writers, in which case we are probably
not using xTalk at all). What matters to most of us is high level
goals (How can I make my organization more responsive to change?, How
can I help these students learn faster and more deeply?, How can I
make this data more intuitive and functional?, How can I automate
this repetitive task?, etc.), not the inane and removed mechanics of
the language of logic. Sure, I am proud when I solve an algorithmic
or notational problem in my scripting. But then I remember the
original task at hand and the fact that my solution really won't help
anyone else solve the same problem, and that brings even greater
respect for the few nerds who cared about non-nerds and who could
think clearly enough to see that even nerds would benefit from
systems that facilitate natural (pedestrian) human cognition. The
revolution that was "User Level Computing" was the revolutionary idea
that being able to do something was not enough... that making
difficult tasks easy made the real difference between theory and
actual human practice. Einstien wrote down the rule: E=mc2... but
nobody (except maybe the good people of the Manhattan Project) has
built a "Relativity Engine" from it. Making an appliance from theory
is the difference that makes the difference. Thank you Uncle Bill!
Randall
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
