the char number of char 1 of word x

[Randall Lee Reetz]

Hello all,

Thanks to all that have responded and provided suggestions, comments  
and sample scripts.

I would like to think that I have presented my questions and  
suggestions in great detail and with extreme attention to clarity and  
logical flow.  This was and is my intent.

As I have said, I am looking for a universal syntax for a built in  
(flexible) string translation function that would take string  
arguments in any legal chunk argument and return in any other chunk  
type.  In xTalk, typing is determined largely by delimiter.  Which is  
great.  It insures flexibility as one can set the dels for these  
(arbitrary though limited... char, item, word, line) types at will.   
I have not asked for anything beyond the types xtalk already  
supports.  However, if pressed, I would suggest a custom form of  
declaring types by delimiter that would do to chunk types what custom  
properties does to properties:

define chunk "set" with del "~" [of this window]
set the del of [chunk] set to ":"
define chunk "record" [of this window]
set the del of [chunk] record to "•"

put record 2 of set 4 of thsData into thsRecord


But back to the topic of string chunk translation function syntax.   
Offering a simple and universal syntax for the retrieval of inclusive  
chunk arguments is essential for fast and intuitive text / data  
parsing and manipulation. You (and other respondents) are correct in  
pointing out that this intent can indeed usually be accomplished  
through some simi-tricky custom functions with a few fairly simple  
lines of script.  However, in the spirit of High or User level  
programming (for the rest of us), in the interest in xTalk-ing these  
affordances, in the interest in what I preach: "Generalize and  
Subsume", I am suggesting a simple and very universal syntax for this  
kind of chunk (x) argument to chunk (y) argument that would really  
make a lot of powerful and complex string parsing and manipulation  
cognitively available to the average joe.

It is that simple.  My first inquiries on this vein were to determine  
if such a syntax and functionality was already pre-existent in Rev.  
As it became obvious that this functionality didn't exist, my follow  
up posts were to suggest a way to build said functionality into the  
lexicon and grammar in the most xTalk of ways.  It is difficult  
discussing that which doesn't yet exist.  Sorry for any confusions  
that resulted.

Randall



On Jan 1, 2008, at 8:45 AM, Mark Smith wrote:

> Randall, some of the abstract examples you've given are simple to  
> do, and some aren't. But  given that Revolution (like Hypercard) is  
> not a typed language, I'm not sure I'd welcome semi-low-level type  
> ideas like "as string", "as numbered chars" etc.
>
> Perhaps if we had a better idea of your application, we could offer  
> better comments and suggestions.
>
> Best,
>
> Mark
>
> On 31 Dec 2007, at 20:01, Randall Lee Reetz wrote:
>
>> 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
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>