World: r3wp

Like!  Would that work for values? -- [to "<" copy a thru ">" "<" 
return a] ; - returns a if there is a < next?

What would you do when you need to process the data a bit first ?

eg. You return tags from different places in a rule, and to distinguish 
them you need to also return something extra, by prepending a code 
to the beginning, for example.

That's what code in parens is for. The USE directive will make that 
safer.

I don't think that returning values would really work because named 
rules are values.

Yes, you're right. Can be achieved with parens, of course.

Looking forward to using USE.

Carl was kinda weirded out by the modifying operations, but I pointed 
out that people do this anyway and get it wrong a lot.

Really ? They look so useful !

They do, but he was weirded out by the idea of PARSE modifying its 
data in place. Apparently he doesn't do that :)

(We can live without them, though.)

What's wrong with that ? Isn't that what RNA does ?

They're going in. If we were just doing what Carl wants, he wouldn't 
need to ask for suggestions and ask me to compile them.

(I mean enzymes that process RNA..)

You mean, Carl has already accepted them ?

Everything in that Parse Proposals page has already been discussed 
with Carl and could go in, barring insurmountable problems with implementation. 
I stopped putting stuff in when he stopped working for the day. There 
will likely be a couple going in tonight, but Carl is actively involved 
in this process.

Well, that sounds all good.

We've already made some changes based on these discussions, which 
is why there are differences from the REPs.

It was freeing when Carl said that we could use modifier keywords 
like ONLY for CHANGE and INSERT. I look forward to seeing how that 
would affect the INTO-STRING proposal :)

The main thing that Carl is concerned about now is that some of the 
proposals make use of the value calculated in a paren on occasion. 
I don't know why this would be a problem, but I'm sure it will be 
worked out or around.

Using 'remove -- a) removing a bracket only at the end of a string 
(as per Graham's example):

	parse "[this]" [remove "[" to "]" remove ["]" end]]

b) where you go down a false path:

	parse "abcdef123" [remove "abc" "123" | remove "abcd" "ef123"]

Would a) work?  Would b) reset the string as the first rule didn't 
match?

a) would work.

b) would not likely reset the string, just like code blocks don't 
undo.

You might be able to do b) like this:

 parse "abcdef123" [use [a] [remove ["abc" a: "123" :a] | remove ["abcd" 
 a: "ef123" :a] to end]]
or like this:

 parse "abcdef123" [use [a] [remove ["abc" a: "123" :a | "abcd" a: 
 "ef123" :a] to end]]

The standard method of putting the longest match first will still 
be the best.

Ooo, I just figured out another possibility for b):

 parse "abcdef123" [to "123" reverse remove ["abc" end] | to "ef123" 
 reverse remove ["abcd" end]]

parse "[this]" [remove "[" to end reverse remove ["]"]]

In reverse, the end is the beginning :)

And the beginning is the end :)

Shorter with tail, perhaps?

parse "[this]" [remove "[" tail reverse remove "]"]

How about this?

	parse "abc" ["a" to end reverse "bc"]

Is there anything that can be done to assist block parsing?

Yup, that would work.

If you turn a string into a block and there's something present which 
is an illegal rebol value ... you get an error.

Is there a way such values can be turned into a legal type ....and 
not get an error?

That sounds like unbound words. In R3 unbound words are not an illegal 
type.

great.

so if we have words like asdfs@ etc, we don't get illegal email types 
etc?

In R2 you just bind the words to system/words, or LOAD instead of 
TO-BLOCK.

That's a different issue, that's illegal REBOL syntax. You are out 
of luck there.

Just don't try to parse illegal REBOL syntax as if it were legal 
and you'll be fine. You have string parse for non-REBOL strings.

Brian, would the above example return true, as the entire string 
has been matched?  Or just work in that it matches the "bc"?

well, if you have a data input screen ... then the user can enter 
all sorts of stuff

Unless that user is trained to enter the right syntax, you'll have 
to clean up before you can load the string.

Chris, the above example would not return true.

String parse is a good way to clean up input :)

Graham, the parser that turns strings of REBOL syntax into REBOL 
data is LOAD, not PARSE. If you want to clean up those strings or 
loosen the syntax, LOAD is the function to change.

On the other hand, you can write a parser in string PARSE that would 
read data in whatever format you like.

I was asking if parsing data could be made easier by altering the 
way values are turned into rebol types

>> to-block " @"
** Syntax Error: Invalid email -- @
** Near: (line 1) @

string parsing is so tedious!