World: r3wp

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!

Now that is interesting. LOAD and TO-BLOCK do that. It would be interesting 
to write a set of rules in PARSE that read REBOL syntax and generate 
REBOL data or warnings instead of errors. For your purposes you might 
consider LOAD/NEXT in a loop inside of TRY blocks.

If you write your own handler for structural delimiters to build 
your own blocks you can use load/next for the simple literal values.

Perhaps to block can convert "illegal" values into strings instead 
of flagging an error?

Personally, I just prefer string parsing with PARSE, but I'm weird 
that way. We're trying to make PARSE less tedious though.

I would rather TO-BLOCK convert illegal values into error values, 
of the syntax error type.

oh well, make it an option for those of us who prefer diffferently

Not up to me. I think that the decision was that relaxing REBOL syntax 
was a slippery slope that would lead to uncatchable syntax errors. 
The syntax error mechanism is one of the most valuable debugging 
tools we have. You might need to consider the possibility that if 
what your users are entering isn't legal REBOL syntax, it isn't REBOL 
syntax and needs a different parser.

REBOL syntax is weird by user standards.

It might be better to come up with a good set of flexible predefined 
PARSE rules for data entry that can be reused without much trouble 
by a variety of programmers. That would solve the problem for everyone 
without making it difficult for REBOL debugging.

to-block/relax :)

You can't do that. TO-BLOCK is a wrapper for TO BLOCK! val and TO 
is an action! with a fixed arity. What you want is a parser for user 
data that isn't in REBOL syntax. That we can do.