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