AltME groups: search

Ladislav, thanks for your comments... I will have a closer look  
on this associativity issue.

Do you have an example where this would make a difference?

I think, that counts as a difference

Now that I take a paper and a pen... left-associativity is indeed 
natural :)

A quick doc to show how to use it?

THat's why parsing reversal and taking care of ** specifically might 
be a good start...

I think I found a way... see you later today (or tomorraow). Again, 
many thanks for your feedback and congrat for your impressive script

It was actually so easy to fix: 5 'append to change into 'insert... 
I still have to check this does not break anything before posting 
a new version on rebol.org.

Ladislav... thank you again for pointing this bug!

Yes... Ladislav reminds me some basic math! God, I felt so stupid 
about this associativity bug! 

The reason why I developped parse-expression.r is because I need 
it to build an companion app for one of the best math book: Calculus 
3d edition from Smith & Minton! For now, I have developped a rebol 
library to transform any vid face into a function plotter, and parse-expression.r 
allows me to use human readable expression in the gui instead of 
guru rebol code :)

Ladislav:

How would you interpret x**-1/2 :
(1) [divide power x -1 2]
or 
(2) [power x divide -1 2]


A previous version of parse-expression.r returned (2)... but i considered 
this as a bug and changed it for (1) (see history 0.9.2 in the header 
of the script). But now, with our discussion on associativity, i 
am not sure anymore... 

Thanks for your help!

hehehe... It has been a long time since I had to implement such a 
challenging problem. It is so fun!

A new version (0.9.5) of parse-expression.r is available on rebol.org 
(http://www.rebol.org/view-script.r?script=parse-expression.r). This 
fixes two bugs I found when writing the documentation, which is also 
available on rebol.org

in R2 is there a single word which terminates all depths of parse 
rules?  I can't remember

That triggers a backtrack to an alternate if there is one.

yeah... I just did a few tests, and it doesn't work in my case, which 
generates and endless rule   :-(

END means end-of-input, not end-of-rule. If you really want to break 
out, try putting the parse call in a LOOP 1 and then BREAK in a paren, 
or in a function and RETURN or EXIT.

ah, loop 1 [] ... good idea   


I guess I can also force the end of the string... by using this old 
trick...
[here: (here: tail here) :here] 

though using break in a loop is much easier in my case.

If you want to fail to an alternate, you can assign the block [end 
skip] to a variable that would normally be set to none, and then 
make references to that variable whenever you want to trigger a failure 
condition.

opt-fail: none

parse "abc" [some [["a" | "b" | (opt-fail: [end skip])] opt-fail]]

If there is only one success and many failures, you can make failure 
the default and set it to something non-failing in the success case. 
If you need to distinguish between failures, set a local variable 
with some distinguishing data. Remember, a predictable failure is 
just an unwanted success.

yeah but I still need to put opt-fail in all rules so its a burden 
I don't need, in fact its even going to slow down the parsing, so 
i'd rather just use a loop   :-)

loop 1 [    parse "abc"   [some [["a" | "b" |  (err-msg: "failed!" 
break)] ]]    ]

Watch out when porting to R3 though, as PARSE itself is considered 
a loop there for BREAK in parens.

If you mean things like "word!", then this is a way:

alfa: charset [#"a" - #"z" #"A" - #"Z"]
numeric: charset [#"0" - #"9"]
alfa-numeric: union alfa numeric

parse "word!" [copy word [some alfa any alfa-numeric "!"] (probe 
word)]

I'm not sure, I understand, but maybe you mean something like:


>> parse [a few words of type word! "string" 1] [some word! string! 
integer!]
== true

Else it would be easier with an actual example.

i know it's suboptimal, just wondering if still possible somehow 
to reject a matching rule later somehow

Ah ok, then you need to convert the word to a series, for example 
a string, and check on last letter:


parse [some word! other* stuff'] [some [set word word! (print last 
form word)]]

It's tricky to reject a rule later, and PARSE has changed over time, 
so I'm not sure.

ok, this is how i imagine a solution would look like:
>> parse [normal-word  word-with-star*] [word! starred-word!]
== true

i would rather use a separate word as a modifier then. makes things 
a lot simpler. maybe i would do a pre-processing 1st to break up 
these words into separate ones

in R2,  the best way is to set a word to the value you're evaluating, 
and conditional to that value's pass/fail, you switch the following 
rule to allow it to continue or track back, so it matches another 
rule.


here is a rather verbose example.  note that this can be tweaked 
to be a shorter rule, but it becomes hard to map out how each part 
of the rules relate.. here, each part is clearly layed out.

rebol []


pass-rule: [none]
fail-rule: [thru end]

condition-rule: pass-rule



parse [
	word-a
	"ere"
	835
	word-b
	15
	word
	86
	bullshit
	#doglieru3
	word-c
][
	any [
		
		[
			; this rule only matches words ending with "-?"
			set val word! 
			[
				[
					(
						val: to-string val
						either #"-" = pick (back back tail val) 1  [
							condition-rule: pass-rule
						][
							condition-rule: fail-rule
						]
					)
					condition-rule
					(print ["PATTERN WORD:" val])
				]
				|[
					(print ["Arbitrary word: " val])
				]
			]
		]
		
		| skip
	]
]

ask ""

in R3 there are some new Parse ops which allow to make this almost 
a one-liner

R3 but obfuscated.

match: [
	  some [thru #"-"] skip end 	(print [w "end with -?"])
	| some [thru #"*"] end		(print [w "end with *"])
]

parse  [
	word-a 	"ere" 	835 	word-b 	15
	word* 	w86	bullshit*	#doglieru3 	word-c
][
	some [
 		  and change set w word! [(form w)]
		  change [do into match | skip] w
		| skip
	]
]

hmm.. thanks a lot guys!
so practically i can fail in R2 by trying to match 'none?

[thru end] is not a good rule to use to fail. A much more reasonable 
rule is [end skip]

Lad   [thru end] means *exactly* the same thing as  [end skip].  
 I don't know why R3 decided to change that, but I find that a regression.

Err, correcting myself

a: [thru end] is supposed to mean the same as a: [end | skip a]

thru is supposed to move the cursor *past* a match,  you cannot go 
past the end, you can only be at the end (the same way you cannot 
go past the tail).

Just try the idiom

a: [b | skip a]

and you will see, that it always means the same as

a: [thru b]

to doesn't match the end... it moves to it..  its different than 
simply putting  end in a rule.  thru is supposed to move PAST the 
result of a to.

>> parse/all "12345" [[to "5"] a: (probe a)]
5
== false
>> parse/all "12345" [[thru "5"] a: (probe a)]

== true

>> parse/all "12345" [[to end] a: (probe a)]

== true


so if I try to move past the end, its logical that it raises a failure, 
since it cannot advance one more character.

In this case there is no right or wrong, its a question of opinion. 
 There is no *after* the end, as far as I am concerned.

Sorry, but it is not a question of opinion.

There may be just a correct implementation or a bug.

The fact, that there is no "advance one character" is quite obvious. 
Every rule matching advances as many characters as the rule being 
matched prescribes. For example, when matching

    parse "aaaaa" [before: "aaa" after: to end]
    index? before ; == 1
    index? after ; == 4


the rule matches a three character string and, therefore, the correct 
position after the match is three characters past the before position 
(not one character, as you incorrectly stated)

Being at it, the following case reveals a PARSE implementation bug:

     parse "aaaaa" ["" to end] ; == false

, since the empty string should match.

no the cursor did not advance.   there are two concepts at play here... 
the notion of index, and the notion of "slots"   a single slot has 
two positions, its start and end, but it has only one index.

a better name for slot, probably is segment... just like in video 
editing.

a matching rule, will expand the segment's area, but not its index. 
 rules are stacked based on end-to segments.  if a rule has a segment 
of size 0 (as in the none rule) there is no index change in the next 
rule segment. i.e. it shares its index since its index is previous 
index + 0

Exactly like the idiom a: [b | skip a], which you did not even try

well... to/thru are listed alongside  skip under "skipping input" 
in both r2 and r3 docs...  they cannot use sub rules, since they 
only do a find on the input.

to/thru do not match subrules... they only do a find.

to/thru do not match subrules

 - yes, that is a correct observation, although unrelated to the subject 
 of the discussion, and, actually, just a detail of the implementation, 
 that can easily change at any time, especially taking into account 
 the user preferences

Although, TO/THRU actually match subrules, when I think about it, 
just a limited set of them.

it really just does a find (even the docs use the term scan).  the 
actual things we can to/thru are exactly the same as what can be 
used in find.

Wow! And I thought, I knew about parse. :-)

A)

As I understand it, matching a rule like [end] is valid and parse 
will return true, if you're at the end, and in this special case, 
the curser isn't advanced further (becuase it's the end). And I understand 
the rule [thru end] as trying to advance the curser past the end, 
which isn't possible, so it fails.

B)

If the rule [end] advance the curser past the end, and this is valid, 
so parse returns true, then the rule [thru end] also should return 
true. But but but this can't be the case, as then this would not 
return true:
parse [a] [word!]

which it does. The reason, it shouldn't return true, is because we're 
at the end, not past the end. Unless both being at the end and past 
the end should return true.


I guess, it's a matter of implementation (as this isn't well documented 
afaik). I prefer the A) situation, as the B) situation is more confusing. 
Don't you agree?

Think of the end of a series as an internal marker, which the user 
shouldn't see as an element in the series, if you ask me.

Oh, I got my understanding from http://www.rebol.com/docs/core23/rebolcore-15.html#section-4
The little example there is a good way to understand it:

page: read http://www.rebol.com/
parse page [thru <title> copy text to </title>]
print text
REBOL Technologies


I was thinking R2, maybe you guys talked about R3 only? Has this 
changed?

I think, the docs match pretty well.
thru	advance input thru a value or datatype


You're right, taking this strictly, we should be able to advance 
thru the end. But this doesn't make much sense, so my guess is, most 
people wouldn't take this strictly, when talking the end of a series.

This is just a speculative interpretation of a text of one example. 
See the documentation.

Keywords that accept a repeat count are:
...
end


So the advancing must stop somehow, as we can parse end multiple 
times.

>> parse [a b c] [to end]      
== true
>> parse [a b c] [to end 5 end]
== true


Anyway, this may be a pointless discussion, if the language isn't 
clearly defined in such detail.

The fact is, that when a rule matches, the cursor may (optionally) 
advance, but it does not need to.

Argh, I was confused by sentences like
Where do you think the cursor is after matching the [end] rule?
:-)
Old def. of thru: advance input thru a value or datatype

New def. of thru: scan forward in input for matching rules, advance 
input to tail of the match


Then it can be argued, the tail of end (of a series) is still the 
end. Or it can be argued, that thru always advance some way further 
(as in all cases except at end). I understand, why [thru end] not 
failing is confusing.

(And stop saying, I should read the doc. I have read it ... in full 
this time.) ;-)

I was confused by sentences like
Where do you think the cursor is after matching the [end] rule?


Interesting, so, you do not know where the cursor is after matching 
the [end] rule? Otherwise, such a question cannot confuse anybody 
knowing where the cursor is.

I said, that, in general, PARSE may, or may not advance the input 
after successfully matching a rule. Which is true.

...how PARSE has grown from R2 to R3

 - actually, not at all. That is only a superficial difference. As 
 can be seen in the


http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse/Parse_expressions


article, (especially it is obvious when the "Idioms" section is examined), 
all the constructs from R3 are possible in R2 as well.

For example,

    a: [opt b]

is actually the same as

    a: [b |]

Interesting. Could it be an idea to 'create' a minimum parse? Maybe 
just the specification.

Has anyone made PARSE as a function? It should be possible, right?

Found a trick to parse integers in blocks. Let's say, I want to parse 
this block: [year 2011]

The rule can't be ['year 2011], because 2011 in this case is a counter 
for number of next element (none here). So normally, I would do something 
like ['year set y integer! ( ... )] and checking the y variable and 
create a fail rule, in case it's not 2011. But this is the trick:

>> parse [year 2011] ['year 1 1 2011]
== true


Two numbers mean repeat the next pattern a number of times, and in 
this case, the pattern can be an integer itself.

I wouldn't call it a trick John, just a non-obvious syntax. I haven't 
used it much, but I wrote a func a long time ago when I needed it 
for something.

literalize-int-rules: func [template /local mark] [
; Turn a single integer value into a quantity-of-one integer
; rule for parse (e.g. 1 becomes 1 1 1, 4 becomes 1 1 4).
	rule: [
		any [
			into rule
			| mark: integer! (insert mark [1 1]) 2 skip 
			| skip
		]
	]
	parse template rule
	template
]

Yes, John, handling of such values has been discussed a while ago. 
That is why in R3 the QUOTE directive has been defined.

In http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse/Parse_expressions#Parse_idioms

The idiom
Description: "Range of times operator"
Operation: 	a: [m n b]
Idiom:	a: [m b (k: n - m) [k [b | c: fail] | :c]]


only seem to be true, when n >= m. When n < m, parse works as if 
the rule was
a: [n b]

Can an R2 parse expert help me with an efficient parse, please?

I've got a set of bbcode-type tags, eg:
    tags: [ "[a]" "[b]" "[cc]" ] 
    

And I've got a data string that includes those (and other) tags, 
eg:

    data: "xxxx[a]aa aa[b]xxxx[a] yyyy[d]yyy[cc]dd[e]ddd[b][A]zz[zz"


What I'd like is the data string split at the designated tags, eg:

    [ "[a]" "aa aa" "[b]" "xxxx" "[a]" " yyyy[d]yyy" "[cc]" "dd[e]ddd" 
    "[b]" "" "[A]" "zz[zz" ]
    
Thanks!

rebol []

=tags=: [ "[a]" | "[b]" | "[cc]" ] 
    
data: "xxxx[a]aa aa[b]xxxx[a] yyyy[d]yyy[cc]dd[e]ddd[b][A]zz[zz"


blk: []
parse/all data [
	start:
	any [
		here: copy tag =tags= there: (
			append blk copy/part start here
			append blk tag
		) start:

		| skip
	]
	(append blk start)
]

?? blk

ask ""

(maybe I misunderstood why you'd want a [ to "[" ] :-)

Steeve, that looks good, thanks!


Only difference from my "expected results" is that you've also returned 
the "pre-tag" "xxxx" .... that's okay -- incidental issues like that 
are completely negotiable in the search for a solution.

> [skip to "[" | end skip]
skip an extra loop by exiting with a fail

sunanda, wrt first elemetn, I thought it was a typo on your part 
 ;-)

:) --- in the real-life app, I'd insert a dummy tag at the start 
to hoover up any pre-tag data.

In R2:

>> parse [a b c [d e f] g h i] [to [d e f] mark: (probe mark) to 
end]
[[d e f] g h i]
== true


Here the block after TO isn't a sub-rule, but a value to search for 
(a block of words). Doing the same in R3:

>> parse [a b c [d e f] g h i] [to [d e f] mark: (probe mark) to 
end]    
** Script error: PARSE - invalid rule or usage of rule: e


Is the block a sub-rule here? I've tried to search the docs, but 
haven't found an explanation.

I think that there is no direct equivalent in R3 to R2's TO/THRU 
inline block. R3's TO/THRU inline block treats the block as its sub-dialect 
for TO/THRU multi, and that doesn't allow complex values or more 
than one value in a single alternate. The direct R3 equivalent of 
what you are requesting would be this, but it doesn't work:

>> parse [a b c [d e f] g h i] [to [[d e f]] mark: (probe mark) to 
end]
** Script error: PARSE - invalid rule or usage of rule: [d e f]

Instead you have to do a trick with to block! in a loop and then 
match the block to quote [d e f] explicitly, keeping looking if it 
doesn't match. It's annoying.

PARSE is definitely something I wish was more open

I have done a bit of work on a function version of PARSE. Maybe having 
PARSE as a normal REBOL function could help in fixing bugs? My version 
is not quite ready to publish. Are there a set of PARSE tests somewhere, 
that I could test my version against? I would prefer R2 tests to 
start with. I'm doing my own tests, but maybe we have a more complete 
set of tests somewhere, like in the R3-alpha world (I think, was 
the name), where we did a lot of tests on different things.

I would be happy to use a function! version of PARSE since i never 
had to do time critical parsing.

not yet, I maybe could do a quick test...

>> dt [loop 100000 [bparse [a b c] ['a 'b 'c]]]
== 0:00:00.965689
>> dt [loop 100000 [parse [a b c] ['a 'b 'c]]] 
== 0:00:00.235949

bparse is my block parse function.

>> dt [loop 10000 [bparse [a b c a b c] [2 thru 'b 'c]]]
== 0:00:00.133237
>> dt [loop 10000 [parse [a b c a b c] [2 thru 'b 'c]]] 
== 0:00:00.029891

So a factor 4 or so.

Geomol: "Are there a set of PARSE tests somewhere, that I could test 
my version against?" - there are the core tests at

https://github.com/rebolsource/rebol-test


, that contain a couple of PARSE tests in the functions/series/parse.r 
section. It would be nice if you added some tests.

What's the opinion on this?

>> parse [a b] [set w ['a 'b]]
== true
>> ? w                      
W is a word of value: a

It seems to work the same as: parse [a b] [set w 'a 'b]
Same in R2 and R3.

Then something is wrong with the basic setup. When starting boron-gl 
alone, you should get a normal Boron console where you can try some 
functions

what normally would appear in a terminal, is put into system.log 
(wrong place)

Petr is right that the gathering of people creates a powerfully positive 
atmosphere. In fact, organising this conference was extremely frustrating, 
to the moment that I didn't feel like doing it anymore, being there 
was wonderful, and now that we're back home, I'm immediately plunged 
back into the frustration again. It's a rollercoaster

Kaj - just a note - RebCon was NEVER an official name of REBOL conference 
IIRC. It was REBOL DevCon. At least 2005 (Italy) and 2007 (France) 
say so.

And as for me - I don't really care. All I care about is when ppl 
meet. That helps a lot to be more tolerant, spread a good atmosphere, 
and make friends.

I thought you did a talk on cURL binding so R3 was represented

By the way, it looks like we'll be able to get a video stream up 
next time

This is a deeplink to the start of the Red presentation http://www.youtube.com/watch?v=6BsQSBCU3Eg&feature=player_detailpage#t=1535s

unfortunately YouTube does not provide the possibility of deep linking 
into movies which are part of a playlist, so context of playlist 
gets lost

A short message on Rebol Week : http://rebolweek.blogspot.com/2011/03/reborcon-2011-quick-report.html

Nicolas, you can embed a deep link to the start of the Red presentation 
after 25 minutes in the film:

I need to re-factor the code a bit as we have a commercial extension 
that is currently included in the main source-code. So I need to 
seperate these, to release the public part.

I would be very grateful if anyone can give me a hint what's going 
wrong here. Thanks.