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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
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
_______________________________________________
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
