Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Linguistic influences

 [1/22] from: joel:neely:fedex at: 11-May-2002 9:29


Hi, all, The discussion stimulated by Tim's question on internal dots reminded me of a question (about REBOL and other things as well) that I've pondered over the years. Since this list has a very eclectic, erudite, international population, perhaps someone can shed some light for me. Please consider the following paragraphs: Paragraph 1 ----------- From my decades-ago one year of college German, it seemed that one deeply nested with many subordinate qualifiers, subtle variations in meaning to express, (at least in literary style) sentences can construct. This style a certain degree of mental discipline and attention span (and perhaps a deep "mental stack") to understand requires. Paragraph 2 ----------- American English is different. We move quickly through an MTV, evening-news-sound-bite world. Brevity is the soul of wit. Don't make me think. Just spit it out. Hemingway was brilliant. I'd be happy to have some of our German-speaking friends (and perhaps others not hampered by English as a native language) to comment on whether Paragraph 1 is a plausible word-order construction for German, or whether it is just a bad parody concocted of too many elapsed years and too little understanding. What does this have to do with REBOL??? Please consider the following function definitions: insflatten: func [b [block!] /local front] [ either empty? b [ copy [] ][ head insert insflatten next b either block? front: first b [ insflatten front ][ front ] ] ] flattenins: func [b [block!] /local result front] [ either empty? b [ result: copy [] ][ front: first b result: insflatten next b either block? front [ insert result insflatten front ][ insert result front ] ] result ] Both of these functions return a "flattened" block containing all of the data from an arbitrarily-nested argument block, without destroying the structure of the argument itself, as in:
>> foo: [[[0 1] 2 [[3] 4] 5] [[6]]]
== [[[0 1] 2 [[3] 4] 5] [[6]]]
>> insflatten foo
== [0 1 2 3 4 5 6]
>> flattenins foo
== [0 1 2 3 4 5 6]
>> foo
== [[[0 1] 2 [[3] 4] 5] [[6]]] It seems to me that INSFLATTEN is stylistically analogous to Paragraph 1 as FLATTENINS is to Paragraph 2. The first (in each case) uses a nested thought structure, while the second is more choppy and uses simpler structures. Here, then is my pondering... What is the extent to which a person's native (or habitual) language influences that person's mental habits? Do those influences then emerge in other kinds of behavior, such as programming style? If my recollection of German literary style is not too flawed, would a literarily-oriented German speaker be more comfortable (or more quickly comfortable) with a nested, structured style illustrated by INSFLATTEN than an equally-trained American? Would a "child of the boob tube" be more likely to prefer (or understand...) the style of FLATTENINS than someone more accustomed to thought -ful/-provoking literature? -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [2/22] from: joel:neely:fedex at: 11-May-2002 9:56


Ooops. Typos. Sorry. Corrections below. Joel Neely wrote:
> flattenins: func [b [block!] /local result front] [ > either empty? b [ > result: copy [] > ][ > front: first b > result: insflatten next b
result: flattenins next b
> either block? front [ > insert result insflatten front
insert result flattenins front
> ][ > insert result front > ] > ] > result > ] >
Doesn't change the real point. (I'm American? ;-) -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [3/22] from: tim::johnsons-web::com at: 11-May-2002 7:45

Re: Linguistic influences/SQL


* Joel Neely <[joel--neely--fedex--com]> [020511 06:45]:
> Hi, all, > > The discussion stimulated by Tim's question on internal dots > reminded me of a question (about REBOL and other things as > well) that I've pondered over the years. Since this list has > a very eclectic, erudite, international population, perhaps > someone can shed some light for me.
I wrote only in C for many years, than transitioned to rebol, then python and perl. What I'm finding is syntaxes of different languages can inform each other. I now have a user-defined rebol functions 'split and 'chomp and I'm using more abstract data typing in Ansi C. Lately I've been learning SQL for applying DocKimbel's mysql-protocol, and it seems to me that SQL could inform rebol syntax. SQL has a sort of natural-ness to it that 'flows' better than C. As for 'isflatten, it occurs to me that I've been looking for that word for some time now. Thanks Joel! -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [4/22] from: gscottjones:mchsi at: 11-May-2002 10:27

Re: Linguistic influences


From: "Joel Neely"
<snip> > What does this have to do with REBOL??? Please consider the
<<quoted lines omitted: 24>>
> result > ]
Hi, Joel, Did you intend to call insflatten from within flattenins? Or were you aiming to have a recursive function call and just had a plan typing "flat" ? --Scott Jones

 [5/22] from: greggirwin:mindspring at: 11-May-2002 11:22


Great post Joel! << What is the extent to which a person's native (or habitual) language influences that person's mental habits? Do those influences then emerge in other kinds of behavior, such as programming style? >> I think the influence will be large indeed, which is one of the things that will make dialects, and the ease with which they can be created, so powerful in the future. I'm not a linguist, but what reading I've done on Transformational Grammars and related subjects has certainly opened my eyes to new ways of thinking (to mix a metaphor or two). --Gregg

 [6/22] from: nitsch-lists:netcologne at: 11-May-2002 21:57


Hi Joel & all, Am Samstag, 11. Mai 2002 16:29 schrieben Sie:
> Hi, all, > The discussion stimulated by Tim's question on internal dots
<<quoted lines omitted: 49>>
> result > ]
ups. that does - (thinking) - urgs. uff. ?? hmm. somehow the first version seems (reformatting) insflatten: func [rest [block!] ] [ either empty? rest [ copy [] ][ head insert insflatten next rest either block? first rest [ insflatten first rest ][ first rest ] ] ] aha! hmm2: all this inserting at front, and recursion? (coding) insflatten: func [rest /into out] [ out: any [out copy []] foreach item rest [ either any-block? item [ insflatten/into item out ] [ insert tail out item ] ] out ] subordinate qualifiers by recursion in loops, but subtle variations in meaning of recursion (full new block/rest of block) are lacking. better material use: seems faster. but lacks the poesy of the recursive version. obviously you coded for example, not performance ;) but IMHO this kind of nesting is more german, more logically. lots of commas works well if you want to impress someone: if he gets a stack-overflow, he would not admit it, so keep adding and ask suddenly "right or wrong?" ;) for poesy i think german is not a stack, its interconnected. a good literary german sentence refreshs a whole world. english is for tourists: "look here! and there! and this!" ;) its a bit like rebols "any[lots of conditons in lots of lines]" instead of englishs "lots of short ifs" somehow. loosely related, a while ago i thought we can say easy "valve of tube of wheel of bike" but "bikes wheels tubes valve"? how about an operator 'of ? ;)
> Both of these functions return a "flattened" block containing all > of the data from an arbitrarily-nested argument block, without
<<quoted lines omitted: 24>>
> accustomed to thought -ful/-provoking literature? > -jn-
-volker

 [7/22] from: lmecir:mbox:vol:cz at: 11-May-2002 23:37


Hi Joel, interesting thoughts. Nevertheless, both your functions look unnatural to me. I think, that the readability isn't optimal. If I had to do the job, I would try to use a simpler algorithm. BTW, what do you want to get in a case like: insflatten [a/b c/d [1] [[2] [[3]]]]? As a human, I would prefer to use a FLAT-APPEND instead: flat-append: func [ series [series! port!] value [any-type!] ] [ either block? get/any 'value [ if not empty? value [ flat-append :series first value flat-append :series next value ] ] [ insert/only tail :series get/any 'value ] :series ] czech-flatten: func [b [block!]] [flat-append copy [] b] ; and the usage: czech-flatten [a/b c/d [1] [[2] [[3]]]] ; == [a/b c/d 1 2 3] -L ----- Original Message ----- From: "Joel Neely" <[joel--neely--fedex--com]> To: <[rebol-list--rebol--com]> Sent: Saturday, May 11, 2002 4:29 PM Subject: [REBOL] Linguistic influences Hi, all, The discussion stimulated by Tim's question on internal dots reminded me of a question (about REBOL and other things as well) that I've pondered over the years. Since this list has a very eclectic, erudite, international population, perhaps someone can shed some light for me. Please consider the following paragraphs: Paragraph 1 ----------- From my decades-ago one year of college German, it seemed that one deeply nested with many subordinate qualifiers, subtle variations in meaning to express, (at least in literary style) sentences can construct. This style a certain degree of mental discipline and attention span (and perhaps a deep "mental stack") to understand requires. Paragraph 2 ----------- American English is different. We move quickly through an MTV, evening-news-sound-bite world. Brevity is the soul of wit. Don't make me think. Just spit it out. Hemingway was brilliant. I'd be happy to have some of our German-speaking friends (and perhaps others not hampered by English as a native language) to comment on whether Paragraph 1 is a plausible word-order construction for German, or whether it is just a bad parody concocted of too many elapsed years and too little understanding. What does this have to do with REBOL??? Please consider the following function definitions: insflatten: func [b [block!] /local front] [ either empty? b [ copy [] ][ head insert insflatten next b either block? front: first b [ insflatten front ][ front ] ] ] flattenins: func [b [block!] /local result front] [ either empty? b [ result: copy [] ][ front: first b result: insflatten next b either block? front [ insert result insflatten front ][ insert result front ] ] result ] Both of these functions return a "flattened" block containing all of the data from an arbitrarily-nested argument block, without destroying the structure of the argument itself, as in:
>> foo: [[[0 1] 2 [[3] 4] 5] [[6]]]
== [[[0 1] 2 [[3] 4] 5] [[6]]]
>> insflatten foo
== [0 1 2 3 4 5 6]
>> flattenins foo
== [0 1 2 3 4 5 6]
>> foo
== [[[0 1] 2 [[3] 4] 5] [[6]]] It seems to me that INSFLATTEN is stylistically analogous to Paragraph 1 as FLATTENINS is to Paragraph 2. The first (in each case) uses a nested thought structure, while the second is more choppy and uses simpler structures. Here, then is my pondering... What is the extent to which a person's native (or habitual) language influences that person's mental habits? Do those influences then emerge in other kinds of behavior, such as programming style? If my recollection of German literary style is not too flawed, would a literarily-oriented German speaker be more comfortable (or more quickly comfortable) with a nested, structured style illustrated by INSFLATTEN than an equally-trained American? Would a "child of the boob tube" be more likely to prefer (or understand...) the style of FLATTENINS than someone more accustomed to thought -ful/-provoking literature? -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [8/22] from: carl:cybercraft at: 12-May-2002 10:39


On 12-May-02, Volker Nitsch wrote:
> for poesy i think german is not a stack, its interconnected.
poesy ? Doesn't seem to be English /or/ German (according to BableFish). I'm monolingual so wouldn't have anything useful to say on this topic, but will follow it with interest. Nice question, Joel. -- Carl Read

 [9/22] from: jason:cunliffe:verizon at: 11-May-2002 19:34


Hi Joel Really Interesting post. I have wondered about this too and especially since discovering REBOL. I don't speak German, but am fluent in French, with a little Spanish. Aeons ago 5 years of Latin, which profoundly defines much of French, Italian, Spanish, and also German too I believe. My wife is Korean, and even when she now speaks fluent English, there fascinating differences in the use of the language. English is very adaptable. The direct minimal Korean style emerges clearly when she writes. I am particularly curious how REBOL might be received in Korea and Japan. My instinct is that it would be much loved if known. And generally, I want to know it's more 'comfortable' to Far East Asian programmers, whose languages dispense with prepositions and lots of extra re-affirming linguistic interconnections. Our [English] prepositions are rather like all that unnecessary punctuation most languages insist upon. To my un-educated ear, Korean word/though order is very direct and 'stream'-like in the same way REBOL is. But REBOL combines a streaming left-to-right flow with insert expansions. Any Japanese/Korean programmers here to enlighten us? ./Jason

 [10/22] from: greggirwin:mindspring at: 11-May-2002 21:13


Hi Carl, poesy = "poetry" --Gregg

 [11/22] from: joel:neely:fedex at: 11-May-2002 21:47


Hi, Volker and Ladislav, Volker Nitsch wrote:
> aha! hmm2: all this inserting at front, and recursion? (coding) >
...
> obviously you coded for example, not performance ;) >
Absolutely! I'm under no illusion that the sample code offered was the best algorithm/approach for the problem. That the first version was just leftovers from some benchmarking I had done a while back -- it was just the first fragment of code that came to hand that had some deeply-nested expressions. I assure one and all that I do NOT recommend constructing blocks from right to left! Of course, that sentence betrays that my native/habitual language is Indo-European-based (reading left-to-right) rather than Hebrew or Arabic (reading right-to-left) or ancient Greek (when written in boustrophedon). -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [12/22] from: carl:cybercraft at: 12-May-2002 16:09


On 12-May-02, Gregg Irwin wrote:
> Hi Carl, > "poesy" = "poetry"
I thought it might have been, but BableFish left it at "poesy" when asked to translate it from German to English... Heh - it's English. "Poems collectively". Poem with an "s" not poetic enough or something? (: Oh well, I don't know all the REBOL words either... -- Carl Read

 [13/22] from: lmecir:mbox:vol:cz at: 12-May-2002 10:55


Hi Volker and Joel, 1) I didn't want to criticize the ineffectivity of the algorithm. I would rather say, that what matters to me may be a "naturality" of the algorithm. 2) Joel's examples as well as Volker's look to me as "top down writing style", while my attempt uses a "bottom up" approach. I am convinced, that the "bottom up style" can be used to improve the readability. 3) Volker is right, that the introduction of iteration using FOREACH simplifies the code. For the comparison purposes, here is an iterative version of FLAT-APPEND: flat-append: func [ series [series! port!] value [any-type!] ] [ either block? get/any 'value [ foreach element value [ flat-append :series get/any 'element ] ] [ insert/only tail :series get/any 'value ] :series ] It is advisable to use the iteration, where it looks more natural/readable (at least in Rebol). 4) I noticed a paradox: the most effective way of assembling blocks is to use APPEND (or INSERT TAIL), but we do not have it as a native. Moreover, the APPEND function should be enhanced to allow the same types of arguments/refinements as INSERT does. (sending as an enhancement request to feedback too). append: function [ {Appends a value to the tail of a series and returns the series.} [catch] series [series! port! bitset!] "Series at point to insert" value [any-type!] "The value to insert" /part "Limits to a given length or position." range [number! series! port!] /only "Inserts a series as a series." /dup "Duplicates the insert a specified number of times." count [number!] ] [path block] [ path: to path! [insert] block: reduce [:path 'tail :series] insert/only tail block get/any 'value if part [ insert tail path 'part insert/only tail block :range ] if only [ insert tail path 'only insert tail block :range ] if dup [ insert tail path 'dup insert tail block :count ] throw-on-error block :series ] The CHANGE function should be enhanced too, to allow ANY-TYPE! VALUE argument. -L ----- Original Message ----- From: "Joel Neely" Hi, Volker and Ladislav, Volker Nitsch wrote:
> aha! hmm2: all this inserting at front, and recursion? (coding) >
...
> obviously you coded for example, not performance ;) >
Absolutely! I'm under no illusion that the sample code offered was the best algorithm/approach for the problem. That the first version was just leftovers from some benchmarking I had done a while back -- it was just the first fragment of code that came to hand that had some deeply-nested expressions. I assure one and all that I do NOT recommend constructing blocks from right to left! Of course, that sentence betrays that my native/habitual language is Indo-European-based (reading left-to-right) rather than Hebrew or Arabic (reading right-to-left) or ancient Greek (when written in boustrophedon). -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [14/22] from: joel:neely:fedex at: 12-May-2002 6:46


Hi, Ladislav, Ladislav Mecir wrote:
> 1) I didn't want to criticize the ineffectivity of the algorithm. > I would rather say, that what matters to me may be a "naturality" > of the algorithm. >
FWIW, the algorithm wasn't the point of my note. I really wish I had chosen a different example. The real point I wanted to focus on was the contrast between deeply nested expressions vs. a long sequence of word-setting expressions to build up the result in an incremental fashion, and the differences in "mental bookkeeping" required to read and understand each.
> 3) Volker is right, that the introduction of iteration using > FOREACH simplifies the code. For the comparison purposes, here
<<quoted lines omitted: 12>>
> :series > ]
Actually, that's still recursive! You refactored the "horizontal" recursion into the FOREACH, but left the "vertical" recursion in place. Here's a completely iterative version of the flattener: nb-flatten: func [ b [block!] /local front result ][ result: copy [] while [not empty? b][ either block? front: first b [ b: compose [(front) (next b)] ][ insert tail result front b: next b ] ] result ]
> 4) I noticed a paradox: the most effective way of assembling blocks > is to use APPEND (or INSERT TAIL), but we do not have it as a native. >
Good observation! -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [15/22] from: rotenca:telvia:it at: 12-May-2002 16:36


Hi all, for me the best mode to do that in Rebol is to use a parse rule: result: copy [] r: [into r | set x skip (insert tail result x)] parse/all serie [some r] It is the more simple and the more fast (i think). But the point is that it also the more easy to understand, if one has a sufficient knowledge of the innatural Rebol parse rules which are distant, i think, from any natural languages rules. So i ask myself what is "naturality".
> 4) I noticed a paradox: the most effective way of assembling blocks is to > use APPEND (or INSERT TAIL), but we do not have it as a native. Moreover, > the APPEND function should be enhanced to allow the same types of > arguments/refinements as INSERT does. (sending as an enhancement request to > feedback too).
I asked for a /tail refinement in insert. It should be also possible to create alias of refined words.
> The CHANGE function should be enhanced too, to allow ANY-TYPE! VALUE > argument.
About Change, I feel the need of a change/part which changes only a fixed length of the destination series with a fixed length of the source series.Now the /part refinement works like insert if the length of the source series is > than the /part argument. Now we must do a copy/part on the source series to do a true fixed lenght Change. If the source is very long, this is a real waste of time and memory. But i could not see a different mode to make it in the current version of Rebol. Anyone see it? --- Ciao Romano

 [16/22] from: joel:neely:fedex at: 12-May-2002 14:15


Hi, Romano, I'm gonna need some help with that one! Romano Paolo Tenca wrote:
> result: copy [] > r: [into r | set x skip (insert tail result x)] > parse/all serie [some r] > > It is the more simple and the more fast (i think). >
But is it correct? Here's what happened when I tried to use the expressions copied from your email:
>> serie: foo
== [[[0 1] 2 [[3] 4] 5] [[6]]]
>> result: copy []
== []
>> r: [into r | set x skip (insert tail result x)]
== [into r | set x skip (insert tail result x)]
>> parse/all serie [some r]
== true
>> result
== [0 0 1 [0 1] 2 [[3] 4] 5 6] in contrast with:
>> nb-flatten foo
== [0 1 2 3 4 5 6] To paraphrase a story from Gerald Weinberg, "If it doesn't have to be correct, I can make it as fast as you want!" ;-) -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [17/22] from: g:santilli:tiscalinet:it at: 12-May-2002 22:26


Hi Romano, On Sunday, May 12, 2002, 4:36:52 PM, you wrote: RPT> I asked for a /tail refinement in insert. It should be also possible to create RPT> alias of refined words. What do you mean? RPT> About Change, I feel the need of a change/part which changes only a fixed RPT> length of the destination series with a fixed length of the source series.Now That was change's behavior before 2.2 or so. I don't think they'll change it back... RPT> But i could not see a different mode to make it in the current version of RPT> Rebol. Anyone see it? remove/part + insert/part ? Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [18/22] from: rotenca:telvia:it at: 13-May-2002 0:30


Hi Gabriele
> RPT> I asked for a /tail refinement in insert. It should be also possible to
create
> RPT> alias of refined words. > > What do you mean?
head insert/tail "ab" "c" =="abc" alias my-append insert/tail head my-append "ab" "c" =="abc"
> RPT> About Change, I feel the need of a change/part which changes only a
fixed
> RPT> length of the destination series with a fixed length of the source
series.Now
> That was change's behavior before 2.2 or so. I don't think they'll > change it back...
I think it could be a new refinement, like /length head change/lenght "abc" "def" 2 =="dec"
> RPT> But i could not see a different mode to make it in the current version
of
> RPT> Rebol. Anyone see it? > > remove/part + insert/part ?
Now I do: change-length: func [dest source length][ change dest copy/part source length ] head change-length "abc" "def" 2 == "dec" de is copied twice and new memory allocated for it every time. (my real "de" is 1 Mb long!) This doesn't seem more fast: change-length2: function [dest source length][x][ x: "" change dest head insert/part clear x source length ] head change-length2 "abc" "def" 2 =="dec" --- Ciao Romano

 [19/22] from: rotenca:telvia:it at: 13-May-2002 0:04


Hi Joel,
> > result: copy [] > > r: [into r | set x skip (insert tail result x)]
<<quoted lines omitted: 3>>
> But is it correct? Here's what happened when I tried to use the > expressions copied from your email:
As you told us, it is not the example, but the idea.:-) There was an error, the position of 'some. This should be correct: result: copy [] r: [some [into r | set x skip (insert tail result x)]] parse/all serie r If it doesn't have to be correct, I can make it as fast as you want! When the new version flies, probably there is something wrong (a debugging rule of mine :-) --- Ciao Romano

 [20/22] from: lmecir:mbox:vol:cz at: 13-May-2002 11:02


Hi all, the discussion on block parsing reminds me of one block-parsing specific problem. Let's suppose, that I want to find out, whether a parsed block contains a sequence of values like e.g. [1 a: :a] Attempt #1: parse [1 a: :a] [1 a: :a] ; == false Attempt #2: parse [1 a: :a] [1 1 1 1 1 a: 1 1 :a] ; == true We see, that the second attempt worked. This solution doesn't work, if I want to test, whether the block contains a specific lit-word like e.g. 'a. Attempt # 3: parse ['a] [1 1 'a] ; == false Summary: for the complicated cases it would be nice to have something like (hypothetic!): parse [1 2 3] [literally [1 2 3]] ; == true -L

 [21/22] from: carl:cybercraft at: 13-May-2002 22:58


On 13-May-02, Ladislav Mecir wrote:
> Hi all, > the discussion on block parsing reminds me of one block-parsing
<<quoted lines omitted: 4>>
> Attempt #2: > parse [1 a: :a] [1 1 1 1 1 a: 1 1 :a] ; == true
That at least could be shorterned to... parse [1 a: :a] [1 1 1 1 a: 1 :a] ; == true
> We see, that the second attempt worked. This solution doesn't work, > if I want to test, whether the block contains a specific lit-word > like e.g. 'a. > Attempt # 3: > parse ['a] [1 1 'a] ; == false
Nope - can't find a solution... ):
> Summary: for the complicated cases it would be nice to have > something like (hypothetic!): > parse [1 2 3] [literally [1 2 3]] ; == true
Yes, a good idea. -- Carl Read

 [22/22] from: rotenca:telvia:it at: 13-May-2002 14:44


Hi Ladislav,
> parse ['a] [1 1 'a] ; == false
It seems to me there that this is a consequence of aggressive evaluation:
>> parse [a] [1 1 'a] ;== true
parse try to check a word and not a lit-word and we can't use a get-word in a parse block:
>> b: to-lit-word 'a ;== 'a >> type? b ;== word! >> type? :b ;== lit-word!
Now this check the word! a not the lit-word! 'a parse ['a] [1 1 b];== false this check the get-word :b not the value of b parse ['a] [1 1 :b];== false while in this case :b is used as a parse command parse ['a] [:b];== false Also 2.5 has this side effect in spite of the less aggressive evaluation. --- Ciao Romano

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted