AltME groups: search

I'm more concerned about the first and follow sets - doing that wrong 
could mean a slowdown of orders of magnitude.

BrianH: "How does your reverse code handle "aa+", or "aa+a"" - damn... 
:)

Anyway, today I was thinking about different way how to do it, had 
no time to code it yet.
It's slow, I know...

I've been thinking about ways to do this too - you got me going. 
I was also thinking of a way to cache charsets for later reuse.

didn't you guys try using a charset?  I would guess its an order 
of magnitude faster still... no?

>> t0: now/time/precise loop 10 [parse data [some #"a"]] now/time/precise 
- t0
== 0:00:06.389


>> t0: now/time/precise loop 10 [parse data [some [#"b" | #"a"]]] 
now/time/precise - t0
== 0:00:25.496

>> b: charset "ab"

>> t0: now/time/precise loop 10 [parse data [some b]] now/time/precise 
- t0
== 0:00:06.379

I'm not sure how can I test for end in case like this:
r: ["a" "b" "c" end] parse "abc" [some [r/1 (r: next r)]]
anybody?

r: ["a" "b" "c" break] parse "abc" [some [r/1 (r: next r)]]

So I left tail-parse becuase of the "aa+" problem mentioned by BrianH. 
I wrote 'lazy-parse that works different and it seems to handle both 
cases "a+a" and "aa+" well.

>> lazy-parse "aaa" [[#"a"][some #"a"][#"a"]]
== true
>> lazy-parse "aaa" [[#"a"][some #"a"]]
== true
>> lazy-parse "aaa" [[some #"a"][#"a"]]

just a quick idea:

FORALL is implemented as mezzanine function. It calls FORSKIP which 
is mezzanine also. As you can see, it's probably not the fastest 
method. So here's the idea. Cannnot be FORALL rewritten to make it 
faster and is it possible to use PARSE to do this?
So I tried and came up with this simple function:

parall: func [
	'word body
	/local data
][
	data: get :word
	parse data compose/deep [

  some [(to set-word! word) any-type! (to paren! [do bind body :word])]
	]
]

(parall is just a shortcut for parse version of forall).


this is very simple function written in five minutes and not very 
well checked, it needs some additional work (eg. it does not return 
same value as 'forall etc).

So let's do some test (using Ladislav's %timblk.r):
>> n: copy [] repeat i 100 [append n i]

== [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 4...
>> time-block [forall n [b: n/1 + 1]] 0.05
== 3.623046875E-4
>> time-block [parall n [b: n/1 + 1]] 0.05
== 3.814697265625E-6
>> 3.62e-4 / 3.81e-6
== 95.0131233595801

95x faster? whooo....

and what about bigger block?

>> n: copy [] repeat i 10000 [append n i]

== [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 4...
>> time-block [forall n [b: n/1 + 1]] 0.05
== 3.540625E-2
>> time-block [parall n [b: n/1 + 1]] 0.05
== 3.7994384765625E-6
>> 3.54e-2 / 3.8e-6
== 9315.78947368421

9000x ? omg...

comments?

; Try against this, the forskip code with the skip part taken out
forall: func [
    "Evaluates a block for every value in a series."
    [catch throw]

    'word [word!] {Word set to each position in series and changed as 
    a result}
    body [block!] "Block to evaluate each time"
    /local orig result
][
    if not any [
        series? get word
        port? get word

    ] [throw make error! {forall expected word argument to refer to a 
    series or port!}]
    orig: get word
    while [any [not tail? get word (set word orig false)]] [
        set/any 'result do body
        set word next get word
        get/any 'result
    ]
]

If you want to test the speed of parse, replace the any-type! with 
a skip - the forall you are comparing it to doesn't do that test.

Sort of like the opposite of break. It breaks one iteration of a 
loop and continues at the top of the next iteration. Many languages 
have it, as does REBOL 3.

but... as long as we're not replacing forall... this could be a very 
fast alternative to use in cases when you don't need all the features...

Oldes: does using () inside a parse loop slow things down? I'm wary 
of () as they do seem to slow the interpreter down in many cases.

What about a new word “all” which would allow  to parse several successives 
conditions whatever their order  ?

parse [a: 1 b: 2] [all ['a: integer! | 'b: integer!]] would be true 
only if it exists successivly [a: integer!] and [b: integer! ] whatever 
their order

Umm...I'm not really a parser but


parse [a: 1 b: 2] [set-word! integer! set-word! integer!] returns 
true.

yeah but what ? if the entry is [b:2 a:  1] instead

but if the entry is more complex like [a: 1 huge tight  b: 1] and 
that i want parse all this values in any order ?

and in your example , you don't test that we must encounter 'a and 
'b

i give another one example , more simple

i want to parse the serie "ABC" but it could be the serie "BCA" , 
"CBA" , "ACB" ... any combination

so if i could write parse "ABC" [all ["A" | "B" [ "C" ]]  , it should 
be more simple

Again, I'm not a parser, but parse's support of alternates with some 
and any covers these cases no?

if you write  parse "AB" [some ["A" |  "B" | "C"]]

parse "ABC" [ 0 1 "A" | 0 1 "B" | 0 1 "C"] ?

you get a true answer, but that not the case

Thinking about this one, you'd have to repeat all the alternatives. 
 Defeating the purpose...but I'll bet Chris or Geomol or Anton or... 
will have a workable solution posted before ya know it.

i h'ave many alternatives (all comsuming lot of code)  that's not 
the point, i just think it could be more elegant to have such a command

Maybe we could hold side bets on which rebol will come up with the 
solution first...I'd put money down on Oldes or Volker giving you 
a workable  :)

try this... parse "AB" [some ["A" |  "B" | "C"] | none 
]

I tried  parse "AB" [some [1 "A" | 1 "B" | 1 "C"] | none]   ...returns 
true

just never use an ''opt" rule in a some or any block

will it just be instances of A B & C?

the awaiting result is 
a: b: c: false

parse "CAB" [some ["A" (a: true) | "B" (b: true) | "C" (c: true)]] 
if all [a b c ] [print "ok"]

(should increment a b and c instead using boolean)

parse "ABC" [3 [1 "A" | 1 "B" | 1 "C"]]  ?

I think I have it
define a rule;
rule: [1 ["A" | "B" | "C"]]
then parse
parse "cAB" [[rule] [rule] [rule]]

I was thinking the same thing, removing each character from a block 
as each rule is processed.

yeah i would use a clean dialect , cause i have many many rules of 
this type

what about a 'unique function or something that tests the string 
for unique characters?

as i said , it was just an example , in fact in my case: "A" "B" 
and "C" are complex subrules, so unique don't apply

Will there be more than three rules possible?  You indicate "A" "B" 
and  "C", but could another instance of this also have a fourth character?

so the parse string would be better indicated something like "A B 
C" where each of those characters could be a sentence?

I guess I don't understand why a unique function wouldn't work as 
a test prior to parsing.

... and of course 'unique shouldn't be used as a name due to Rebol 
already having a unique function.

Ok, this is convulted and probably wrong


rule: [copy res subrule (remove/part find subrule compse [| (res)] 
2)]
subrule: ["filler" | "a" | "b" | "c"]
parse "fillerabc" [4 [rule] end]


Remove the alternatives from the rule as you find them...the filler 
is to allow | "a" to be found.

take a whisky on the rocks

i got a beer

This has it...
r1: "A"
r2: "B"
r3: "C"

rule: [opt [r1 r2 r3]]

parse "ABC" [[rule] [rule] [rule]]

so i have to build a pre-parser to transform rules in an elegant 
maner

I'm still slowly backing out of the room...but I would not be completely 
surprised if another rebol gives you a "tada" solution...but I'd 
bet less money now.  :)

Basically you're asking for [all ["A" | "B" | "C"]] -->
ABC
 = true
BAC
 = true
BBC
 = false
ABCB
 = false

I think Steeve just left...but yep he wants a once and once only 
in any order

assuming "A" "B" and "C" could be more complex rules

You may want to check Gabriele's 'compile rules' to see if this has 
been solved.  I have another solution, but needs hashed out a little.

i know how to build a complex solution but i would prefer a new word 
in the dialect , if other peoples think it's a good improvment

I think so -- it's a common enough pattern...

unfortunately the cat did not type a useful parse rule.

steve - not sure this should be a new dialect word, since it is a 
very specific case. basically you want all permutations of a set 
of rules.

that is, parse string [a b c | a c b | c a b | c b a | b c a | b 
a c]

i give another one example: imagine you have a dialect which describes 
a rectangle with coordinates length and color.

You could write [rectangle 10x20 300 red] but [rectangle 30 red 10x20] 
should be correct too (and other combinations).
So a parser should handle this with not too much complication.

that can also be written as: parse string [a [b c | c b] | b [c a 
| a c] | c [b a | a b]]  (faster)

Steeve: In that situation, you have a little discretion to ignore 
excess attributes, as VID does.

you make a function that taken a list of rules generates all the 
permutations.

ok, it was a bas example

but i have just posted here because i thought it will be a good improvment 
to have a new word in parse dialect

The workarounds do seem a little unwieldy, but I'm not sure what 
the complexity in the proposed 'all keyword would be...

this is possible, but my guess, that Steeve would call it ugly too:


>> once-only: func [rule] [use [rule'] copy/deep [rule': :rule [rule' 
(rule': [end skip])]]
]

>> rule: [(a': once-only a b': once-only b c': once-only c) 3 [a' 
| b' | c']]

== [(a': once-only a b': once-only b c': once-only c) 3 [a' | b' 
| c']]

Ladislav, that's not ugly, it's beautiful! :-)

I have a question though. Do you need the skip at the end of once-only? 
Wouldn't it work just with
rule': [end]

To do block parsing, I suggest:

>> once-only: func [:rule] [use [rule'] copy/deep [rule': :rule [rule' 
(rule': [end])]]]

>> rule: [(a': once-only 'a b': once-only 'b c': once-only 'c) 3 
[a' | b' | c']]
>> parse [c b a] rule
== true

John: [end skip] is a rule that surely fails, while [end] may succeed 
(at end)

>> once-only: func [rule] [use [rule'] copy/deep [rule': :rule [rule' 
(rule': [end skip])]]]

>> rule: [(a': once-only 'a b': once-only 'b c': once-only 'c) 3 
[a' | b' | c']]
>> parse [a b c] rule
** Script Error: Invalid argument: a

in that case you can use either:

    a': once-only first ['a]

or

    a': once-only ['a]

Once (again)

Rebol is amazing, i think i found a simple and elegant dialect

Currently, it's not allowing recursive once usage, but it's obvious 
to do with a stack.


take: func [r] [n: 0 once/1: (length? r) + 1 / 3 once/2/2: r replace/all 
r '.. '.]
.: [(n: n + 1)]
..: [(n: n + 1) end skip]
once: [0 [(if n > 0 [poke once/2/2 n - 1 * 3 + 1  '..] n: 0) []]]


rule: [. "a" | . "b" | . "c"]
parse "CBA" [ (take rule) once]
== true
parse  "BAC" [ (take rule) once]
== true
parse  "CBA" [ (take rule) once]
== true
parse  "BBC" [ (take rule) once]
== true
parse  "CA" [ (take rule) once]
== false
parse  "CABA"[ (take rule) once]
== false
rule2: [. "a" | . "a" | . "b" | . "c"]
parse "CABA"[ (take rule2) once]
== true

I should read the thread  when I have a few minutes

Steve, wondering if your take function solution was coded in french, 
I can't understand it  without studying it a bit more.

do rules: [
	set 'a "first rule "
	set 'b "second rule "
	set 'c "third rule "
]

rule: [ 
	[end (if empty? erode[here: back tail :here]) :here skip]| 
	[here: erode there: 
	(	all[
			token: copy/part :here :there
			word: find rules token
			word: first back word
			remove/part find erode word 2 
		]

  all[empty? erode not tail? there insert/only erode [] there: tail 
  there]
	)] :there
    rule
]

data: "first rule second rule third rule "
erode: [ a | b | c | a]  parse/all data rule

parse "  a" [copy r "a"]

>>r
== " a"

i think it should be r = "a" instead

>> parse/all " a" [any " " copy r "a"]
== true
>> r
== "a"

I try toi allways yse /all when I give a block of rules

r: parse " a" none

["a"]

hi Toms, as always don't focus on the example i give but on the issue 
i suggest, another one example:
>>parse "ld   a  b" ["ld" "a" copy reg ["b" | "c"]]
>> r == " b" 
>> i just think it will be more logic to have r == "b"

We so need a Wiki for Rebol, and shove every word and example into 
it.  Just Parse needs 100 pages of examples and descriptions.

we need a wiki just for parse

and a new book.. Dialects for The Rest of Us (forget the Dummies 
version..)

There is always another trick, and another level to Rebol, the docs 
NEED to be in a Wiki, where we can add to them, let them live, breath...

there is a rebol wikibooks

Yeah, it needs someone to kick it off, get it started, fill it with 
about 50 good words.  Where is a "kid" when you need one?

>> ; insufficent pattern
>> data: "first rule second rule third "
== "first rule second rule third "
>> erode: [a | b | c]
== [a | b | c]
>> parse/all data rule
== false
>>
>> ;;; unused rule before pattern is consumed
>> data: "first rule second rule third rule "
== "first rule second rule third rule "
>> erode: [a | b | c | a]
== [a | b | c | a]
>> parse/all data rule
== false
>>
>> ;;; patterns and rules allowed in any order
>> data: "first rule second rule third rule "
== "first rule second rule third rule "
>> erode: [c | b | a]
== [c | b | a]
>> parse/all data rule
== true
>>
>> ;;; multiple (duplicate) rules allowed
>> data: "first rule first rule second rule third rule "
== "first rule first rule second rule third rule "
>> erode: [a | b | c | a]
== [a | b | c | a]
>> parse/all data rule
== true
>>

a crazy simple alternative from DocKimbel (non repetitive pattern 
and limited to rules with single char)

>> rule: [(c: charset "ABC") 3 [copy v c (remove/part c v)]]

>> parse "ABC" rule
== true
>> parse "BAC" rule
== true
>> parse "CBA" rule
== true
>> parse "ABA" rule
== false
>> parse "ABCA" rule
== false

AFAIK, datatype matching is reserved for block! parsing. IMHO it 
should report a dialect error! in your example. Is string! matching 
supposed to support datatypes in latest core releases, maybe I missed 
an evolution ?

doc, integer! works for strings for some reason. it's the only one 
that works, and seems to match a sequence of digits (not sure if 
it does anything more than that). it's been there since a long time 
(probably from the beginning ;) but not documented.

It looks to me more as a bug than as an intended feature (maybe a 
side effect of the block! parsing addition?). Anyway matching REBOL 
datatypes in string! parsing mode could be a useful feature and would 
make a lot of parsing rules shorter.

is thta a tab?

I'm beginning to wonder if it is a bug in parse

Anyone know how to parse a string such that the newlines and tabs 
are parsed?  I'm not getting the results I'm expecting.

RebTower 0.0.7 has been released.
- All art is now completed.

- Card Builder is included with this release so you can make/modify 
your own cards.

- Added turn pause mode so you can get a better look at the cards 
the computer plays.
Get it at: http://rebol.mustard.co.nz/rebtower-0.0.7.zip(657kb)