World: r3wp

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.

Graham; I've been trying to convince Carl for this   TRANSCODE in 
R3 doesn't throw syntax errors.

what's transcode?

Graham, my 'import (and 'as) function is kindof addresses this.  
I've also been working on loading non-rebol data (in some cases numbers 
that use , -- 1,000 or us-style dates mm/dd/yyyy).  This'll be even 
better with some transformational chops in parse...

The new LOAD/NEXT

I agree that things should be easier to parse - and that includes 
preparing data to be parsed.

Having predefined parse rules is just more stuff to remember.

Oldes? Henrik? Maarten? posted a nice all-value loader for me, its 
in some of the construction boss code, but I don't have that source 
ported to this machine yet...  I didn't learn anything, as I just 
cut'n'pasted the snippet.

any-one!

It's not more to remember, it's just a module to load :)

Can you give me an example of what you are thinking of?

the ability to remove/override/extend the set of chars considered 
"special"  in  string splitting

like " ?

some sql dialects have the handy abilty to set the current delimiter

the abilitty to "recognize all datadypes not just a frw like  integer! 
tag! in string parsing

yes Graham quote is one that can be hard to work around or show up 
unexpectedly

comma and space  seem to be others

block parsing .. you can't match specific integers

Graham - there is going to be a LIT keyword to match integers ....

this may bot be a well formed thought but ... the ability to directly 
feed a port into parse

maybe something like

parse open txcp://where.ever:555 rule

where the closing port would determine when if ever  parse was finished

prt: open ...
parse/port prt [  ...
	insert  prt something
...]

hmm, continuous parse ... there was my request for it long time ago, 
and IIRC even Carl said, that it might be usefull. Imagine for e.g. 
encoders ... You read stream from file in chunks, and you evaluate. 
The problem is, when you need to backtrack, you would need to cache 
the stream. Dunno, if something like that is possible at all ...

I don't like the result of none if parsing strings.


parse/all ",,," [(block: copy [] ) any [thru "," copy a to "," (append 
block a)] to end ]
should give  
>> block
== ["" ""]
and not
== [none none]

My suggested improvement to parse would be a trace (or debug) refinement:
    trace-output-word: copy [] 
    parse/trace string rules trace-output-word 

I'm not entirely sure how it would work. That would depend in part 
on how parse works internally, and so what trace points are possible. 
But, as a minimum, I'd expect it to show me each rule that triggers 
a match, and the current position of the string being parsed.
 parse would  append trace info to the trace-output word


Otherwise, parse is too big a black box for any one other than very 
patient experts.