the char number of char 1 of word x

Randall Lee Reetz randall at randallreetz.com
Mon Dec 31 15:01:38 EST 2007


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





More information about the use-livecode mailing list