AltME groups: search

The way the new behavior would be formulated is this: ANY or SOME 
would only succeed if one of these conditions happened:
- The rule argument fails (after the first round for SOME).
- The rule argument succeeds *and* the position changes.

I have some ideas about how REVERSE and should work with backtracking 
that I haven't written down yet.

and ->

yeah i know it's difficult to create, but when it works it's incredibly 
compact and powerfull, i like compactness

currently when we parsing a serie we can't mix constant string! and 
constant binaries together

That will be moreso in R3 because string! and binary! aren't compatible 
any more.

AS-STRING and AS_BINARY are gone.

Yes, but that is a real conversion, with encoding and decoding.

Just like converting from a .jpg to an image! and back.

The Unicode changes were pretty significant and deep.

DROP, SWAP, ROT and DUP are stack modification operations, not parse 
advancement operations like SKIP. Don't forget REVERSE and matching 
operations - they advance too.

Just some ideas for possible usage.


[[item1 item2 | item2 item1 SWAP] ]   ; Put previous two matched 
items in order.
==> [item1 item2]  ; Always sorted.


[ROT [a b c d e]] ;  Rotate items matched by next subrule, if it 
matches. 
==> [b c d e a]  ; 


[start: a [b c] DUP start]  ; Duplicate items from start to current 
parse index.
==>  [a b c a b c]


[a DROP [b c]] ; If next subrule matches, then remove items matched, 
and set parse index back to the beginning of the remove.
==>  [a]

(DROP is just like REMOVE, so not really needed, I think. Just doing 
the exercise to see.)

The above can be categorized by how they fetch their arguments:
- Take two previously matched items/subrules (like SWAP).
- Match the next subrule (like ROT, DROP).
- Use a variable to take the parse index (like DUP).

not always. if you need maximal speed. and you  trust the data and 
rules.

Steve said in r3-alpha world:

Sometimes some of my parse rules can take overnight to resolve on 
some complex random files...and I would like to be able to set a 
time limit in parse so that if it is recursively grinding on time, 
that I can halt it

And when he returns, if it timed out, he wants to see where it got 
up to.

Maybe you wanted not to have to reduce.  eg:

	parse reduce [ 'integer! integer! ] [ datatype! datatype! ]


would return true, even though only one of the two input values is 
of type datatype!

If that is the case, then I think this came up already some time 
in the past. I think, as then, that it was a bad idea, because it 
causes a distinguishability problem. PARSE would sometimes not be 
able to distinguish between a word! and a datatype!. This would cause 
problems when parsing code, because you would have to test if words 
looked like datatypes, and treat them specially.

Anton, trying creating a word string! and a datatype! string! value 
and insert into a block.  [string! string!]  and then do your testing. 
 I remember discussing this with BrianH when I ran into the issue. 
 I don't have REBOL on the computer I'm currently working from right 
now so I can't present any test at the moment and I'm turning this 
laptop back in to the company soon.

#[datatype string!]  That way we can read data direct from a file 
port and without loading or reducing use parse to identify respective 
datatypes and datatype!.

Actually, if I recall the problem seemed to be using datatype in 
the rule block as follows:   set n datatype!   And it failed to work.

and these:
>> parse [#[datatype! string!]] [set n datatype!]
== true
>> parse reduce [string!] [set n datatype!]
== true

Carl is focussed on the GUI stuff right now, and his feedback is 
needed since he will be using the feature for that.

i like the idea of the non consuming rule AND

i'm wondering if special commands like (PUSH and POP) to save/restore 
the current index when entering in recursive rules would be usefull

i take an example:

to simulate AND we do [here: rule :here] but it can't be used in 
a recursive manner.

If we had PUSH and POP to save and restore the current Index depending 
the level of the recursion (in fact they are stack operations)
So, we could write: AND: [push rule pop]

it could be very interesting and replace USE in many cases

would AND be equivalent to [use [success?] [[(success?: no) rule 
(success?: yes) fail | none] check (success?)]] ?

If it is equivalent, reading your rule, then I full agree to add 
AND :-)

here: :here concept is handy, understandable by beginners in parse 
like me. Adding recursion safety via USE is a good thing. Can't comment 
on AND usability, as I don't precisely understand its meaning ...

Gabriele, that would be one way to do AND (though Peta's workaround 
is probably the most efficient).

AND is a lookahead function, inspired by TDPL theory. Apparently 
PARSE is close to TDPL or PEG grammars, but missing a little.

Well, Peta's additions and changes have been integrated and cleaned 
up. There are more clear guidelines for the project now. Still haven't 
added Gabriele's DO operation yet, though I now know how to do so. 
Anything else?

Reflecting on words -- where does 'and come from?  Reads a little 
awkwardly:

	cmd: [list [everything]]
	parse cmd ['list and block! into ['everything | 'something]]

'at might be more apt?

	parse cmd ['list at block! into ['everything]]
	parse cmd ['list not at [paren! | hash!] into ['everything]]

yeah i agree AND is not the best word for that job.
i prefer [IF] it means what it does...
But it's not a problem for me to keep AND

AND comes from the use of & in the PEG syntax papers, but it could 
also be seen as being like the AND operator in REBOL, prefixed.

Nonetheless, I agree that the names of AND and OF don't make much 
sense. The concept behind AND is sound though.

I have finally adapted Gabriele's DO proposal. Aside from naming 
issues, examples in need of explanation and any nagging questions 
we might be done here, with the exception of feedback from Carl about 
his proposals and any other issues. Anything else?

Added Chris's suggestion for AND to be named AT, and explained the 
advanced AND example (good luck!). If there aren't any more suggestions, 
I think this is ready to go to Carl.

I edited the OF proposal to provide a syntax description similar 
to the other proposals and added your suggestion, Steeve.

ah, can't believe that :-) But - Cyphre would be involved, no? And 
AFAIK he is not :-)

Well then - transparent top window would be fine, but I think that 
more importantly - proper Unicode display should be a priority, and 
maybe looking at R3 alpha demo called button colors - it scrolls 
like molasses - there is either bug and there is more being redrawn 
than what is needed, or we have to think about other optimisations 
(e.g. I remember some 2 years ago Carl stating, that View might still 
render unnecessary things ...)

... another option I remember was to switch to compound rasterizer 
of AGG. And - REBOL timers are still substandard of what can be achieved 
imo ... But, as Carl said - those parts are going to be host part, 
hence open-source. We just need Carl to release sources. Hopefully 
it happens till I retire :-) (eventual replies to REBOL3 group, just 
wanted my comments to be at one channel)

In the past, there were Gabriele and Cyphre. Gab did initial VID3, 
http protocol and maybe other things. Cyphre did View kernel things 
- e.g. whole compositing engine was replaced by the better one - 
AGG based ...

nowadays Henrik and BrianH are helping with VID 3.4.

Peta seems to have agreed with you, Chris, and changed the name of 
AND to AT. Things have settled down to grammar fixes.

and in your example, to return back even after the change.
at rule at change value

CHANGE basically needs the same information that the CHANGE REBOL 
function needs:
- A start series/position
- An end position or length
- A value to replace with
- Some options, if you need them

The CHANGE proposal has all those, and there isn't much more we can 
simplify it :)

Kind of a necessary bonus though, since it lets you specify what 
you want to change. You need to have the change operation before 
the rule so you know where the rule starts and where it ends.

If I'm getting this right, OF is designed to do this:

	blk: [1 two 3.0]
	parse blk [of [integer! word! decimal!]]
	== true
	parse blk [of [number! word!]]
	== false (only accounts for one number)
	parse blk [of [word! decimal! string! issue! integer!]
	== true (can be none if a given type is missing)


I have another scenario to which the word 'of would apply.  There 
are situations where I want to match one item from a block of options. 
 Currently, those options need to be pipe-separated, requiring preprocessing 
if those options come from a data source (see languages: in my emit-rss 
script for an example).   This appears in both string and block parsing. 
 An example (using IN as the hypothetical operator):

	m28: ["Feb"]
	m30: join m28 ["Apr" "Jun" "Sep" "Nov"]
	m31: join m30 ["Jan" "Mar" "May" "Jul" "Aug" "Oct" "Dec"]
	b28: repeat x 28 [append [] 29 - x]
	b30: repeat x 30 [append [] 31 - x]
	b31: repeat x 31 [append [] 32 - x]
	parse date-str [
		in b28 "-" in m28
		| in b30 "-" in m30
		| in b31 "-" in m31
	]

This would be true for "1-Jan" "30-Sep" and false for "31-Feb".

It's complex to explain (or document), but is versatile and consise 
(for what it does).

Steeve, two requests -- matching from a block! and a slightly more 
nuanced 'of

Chris, re: your more nuanced OF, that is covered in the existing 
proposal (including Steeve's alternate and Carl's possible future 
extensions). Carl will have to determine how flexible OF can be implemented, 
without having diminishing returns on increased complexity.

Your example with alternates (and bug fixes, still ignoring leap 
years):


 m31: ["Jan" | "Mar" | "May" | "Jul" | "Aug" | "Oct" | "Dec"]  ; joins 
 were in wrong direction
	m30: join m31 [| "Apr" | "Jun" | "Sep" | "Nov"]
	m28: join m30 [| "Feb"]

 b28: next repeat x 28 [repend [] ['| form x]]  ; next to skip leading 
 |, numbers don't work in string parsing
	b30: ["29" | "30"]  ; optimization based on above reversed joins
	b31: ["31"]
	parse date-str [
		b28 "-" m28
		| b30 "-" m30
		| b31 "-" m31
	]

The above with CHECK instead:

	m31: ["Jan" "Mar" "May" "Jul" "Aug" "Oct" "Dec"]
	m30: join m31 ["Apr" "Jun" "Sep" "Nov"]
	m28: join m30 ["Feb"]
	b28: repeat x 28 [append [] form x]  ; not assuming 
	b30: ["29" "30"]  ; optimization based on above reversed joins
	b31: ["31"]
	parse date-str [
		copy d some digit "-" copy m some alpha
		check (	any [
			all [find b31 d  find m31 m]
			all [find b30 d  find m30 m]
			all [find b28 d  find m28 m]
		])
	]

Which would be faster would depend on the data and scenario.

Your proposal seems like a slightly faster but more limited version 
of alternates, and not as flexible or optimizable as check. Does 
this situation come up so often that you need direct support for 
it?

'append would do it...

numbers don't work in string parsing

 - I thought about this when I developed the example, thought it might 
 be possible as the numbers appear outside the dialect.  But 'check 
 seems like the better option.  

joins were in the wrong direction
 - d'oh!

simpler date checker

 - that's only useful if to-date recognizes the date format : )  (and 
 using dates was illustrative - there are other situations with similar 
 needs).  Though on dates, what would be the most succinct way with 
 the proposals on the table to do the following?

	ameridate: "2/15/2008"
	parse ameridate ...rule...
	newdate = 15-Feb-2008

One attempt:

	parse ameridate [
		use [d m][
			change [copy m 1 2 digit "/" copy d 1 2 digit]
			(rejoin [d "/" m])
		]
		"/" 4 digit end check (newdate: to-date ameridate)
	]

(and that it's ok tomodify the original string)

If I am parsing something like javascript that has { and } in it 
like C, how can I put that into a string to parse without using {}

I think I raised the same question on the ML years ago, and got  
a disappointing answer. Maybe things have changed since. Or, if not, 
it may not be too late to add to the R3 parse wishlist:
    http://www.rebol.org/ml-display-thread.r?m=rmlSQHQ

My first inclination is to "go binary" on it...;-) but that is inelegant, 
and the MSB of binary gets wonky sometimes.

In the console if you type a {  and then hit Enter, it continues 
on the next line.

:{   and }:   don't seem to work, either.

that's the old XON/XOFF sw handshaking trick.


So you mean to add ^ in the Javascript, and then wrapping it with 
{} won't cause a script error?

Robert, your rule steps INTO the second a/1, and then, I suppose, 
fails to reach the end of it.

Show us the INTO rule, and we will tell you what is wrong with it. 
PARSE will treat the path a/1 like the block [a 1] eg:
	>> parse [a/1][into [here: (print mold here) 'a 1 1 1]]
	[a 1]
	== true

(You also wrote 'keyword in your rules, but 'mykeyword in your input. 
I'm hoping that was just a typo.)

Thanks for all the helps on parse...I have my new platform working 
100% as of this morning.  The labor of over a year of technology...and 
the code keeps getting smaller and faster.  100% REBOL.  It's all 
dialects.

I've been hoping for these publicly for years... but you won't get 
them.  Competitive advantage, and you have to respect that.  Although, 
if the companies were left nameless and so was the author, then maybe 
he could atleast outline the concept that was involved or the problems 
that were overcome.

I have another month or so before deployment.  Still lots of busy 
work, mostly more parse rules.  I probably shouldn't say much yet, 
but I was excited after a weekend of breakthroughs, and anyway, I 
wanted people to know I am even more heavily invested in REBOL than 
ever.

a month or few and I should be ready to say more.  I just got too 
excited...;-)

Ok, the paren! consume the input, but how can I parse only paren! 
?
your rule work for (a b) and for [a b]

>> parse [[a b]] rule
a b
== true
>> parse [(a b)] rule
a b
== true

...or better, do you know where I can find a simple algebra parse 
script, which can compute simple expression like [1 + (2 /3)] ?
I'm learning how to parse, and such example would be illuminant

it can parse expression like: [- 1 * (a/b + 2)] and it emits a javascript 
compatible string.
(is a part of a comet server written in rebol)

If I change the order of the rules and place the pipe or bar '|' 
as appropriate, I can't get all three of these rules to work together.

Okay Oldes, your solution works, but why does my code fail, any ideas? 
 I have other scenarios that follow this same sort of structure but 
do not have a simple two word expected result.  I've been able to 
handle these so far, simply by changing the order and moving the 
'stop' word of the Ampersand to the bottom of the rule options.  
[I'm trying Chris's option now]

Brock: it'sbecause in rows 52 and 66 you find "+%2b".It'snot next 
to lang value you want, but it's there so the first rule is true.

You can use this if there may be url-encoded data and not encoded 
as well:
lang-chars: charset [#"a" - #"z"]
lang-rule: [
	thru "language" ["%3a" | "="] copy language 2 lang-chars to end
]

Too many recursions.
Maybe the rule is too complex or you get an infinte loop.
Just show your rule and the problem.
For sure someone will help.

example: 


parse/all s [some ["12345" here: (print "*" here: tail here) :here 
skip]]


basically, in the paren, you assing the tail of the data being parsed, 
and force parse to move to it, then try going beyond....  the skip 
makes it return false, otherwise it returns true.

The phrase [end skip] will always fail and return false.

yeah that will work Brian.  i think I was setting the word that I 
had placed at the end and that is why it failed before.

I was the editor of the proposals and manager of the proposal process.

Yeah currently I would just set another value called 'flag in the 
parens and then check it after the parse was complete.  If it was 
true then I know a word wasn't found.

the whole of the enhancements will make PARSE SOOOOOOO much more 
conscice and fun to use for advanced stuff.     :-)

not yet... reading it as I chat, cook and do some income tax stuff... 
I' m a bit like reichart... I've got an exec kernel in my brain  
 ;-)

That idea is to put all the operators (since they are words in the 
words containers along with field names which get later set to values 
and other set-words as desired).

the differentiation is quite subtle, and I am pretty sure that the 
rejected was mine   hehehe.

but new that I  have rebuild remark WITH parse and that I have read 
the proposals, I am in a much better state to explain it, I think.

remark is the basis for my proposal.   I can already to what I propose 
in parse v2... but I beleive it could be done so simply and could 
reduce your first example (the recursive file list) to a 5 line affair.

so I'll try to cook up an example of how it would be used, and the 
effect it would have... then you can tell me if I'm nuts  ;-)

so, I put a lot of thought into it, and with the new stuff... especially 
  'CHANGE  'AT 'ONLY ,  the problem with 'UNFOLD is that its too 
problem specific.

the general idea was to build a system which basically does an:

rule: [ any [at change only [  rule  ]] | skip]


the problem is that what to skip and what to change, differs from 
problem to problem, and since these are tied up within subrules, 
they become hard to use within a generalized procedure.


in R2 the above is pretty harsh to implement, although it can be 
done... with the use of the 'USE operation, these words already make 
recursivity and stack issues pretty easy to tackle..

no I really did a good read, and understand your example... its the 
'AT which does the trick.

but, in R2,  I'm not using it for some reason I don't remember... 
I actually use the change/part within a paren and manually set the 
series using the :here trick.

so I'll go back to the batcave and continue working on remark v2, 
and some other stuff... I want to release since a long time

its fun to be able to read all that stuff about parse and *get* it.

The biggest problem you would have if compiling the new rules to 
their R2 equivalents would be to generate all of the intermediate 
variables and make sure their bindings are not corrupted on recursion.

However the proposal is really big and I think that implementing 
it would not be so easy and fast. Will we see it complete at the 
end of 2009 ? It is only Carl working on it :-(

My main concern is that Carl's main requirements of the proposal 
process have been ignored in some cases:

- That the proposals be concisely specified. The Purpose and Importance 
statements should be one sentence each.
- That there be no discussion of theory.
- That there be no specification of equivalent rules.
- That all discussions happen outside of the wiki.
- That this is a proposals page, not documentation.

aha, I remeber I learned a lot from that green page too.. thanks 
for links so far , I will read the pages and hopefully I will find 
something related to the problems I have

the last problem I had and steeve and oldes propsoed solutions... 
I got steeve's one but I don't get what "complement charset" in olde's 
does.. >>str: "a.b.c.d!e?f. " chars: complement charset ".!?" >> 
parse str [any chars tmp: to end (uppercase tmp)] str == "a.B.C.D!E?F. 
"<<

basically it seems to me right now, PARSE is mega powerfull for anything 
that comes in somewhat PREDEFINED order, like dialects and many other 
things (I could do mulitple html extraction programs with it for 
some search project I was making without hitting this limitation 
- it was predefined order too).. but it seems to get limited at things 
that repeat/exchange themselves at random etc--

Now I see that the above example will require newline at start of 
the input. And that I'm not using the 'stops and 'rest at all:)

Very interesting, both versions (Oldes and Steeve) , thanks a lot.. 
I think I understood most of it now

In the real life for example for syntax highlighting of complex HTML 
page with mixed CSS and JS (etc) with separate lexers for each language.

This weekend I got an interesting idea: algebraic (and recursive) 
data types are well known for their ability to implement parsers. 
And they are a great data modeling tool.

E.g: 

data Bill = Name BankAccount | 
                   Company CreditCard

data CreditCard = CVC2 CCNumber CCExpiryDate 


However, the opposite also holds, i.e you can model data domain using 
named parse rules without actions just as easy. Now, what if you 
would combine two dialects: one to define data structures and a separate 
one to attach actions. 

E.g.

Post: [ message [string!] author [string!] timestamp [date!] ]
Comments: [ some posts]
blog [ 1 post comments]


action 'JSON 'Post [  .... the action to convert the Post to JSON 
here ...]

action 'XHTML 'POST [ ..... the action to convert Post to XHTML here...]

process some-data 'JSON

-> this gives back the data processed as for the JSON actions. It 
is a bit SAX like, with the difference that this models classes of 
action and separates them from the data in stead of scattering some 
lose actions. And, the data modeling still holds.