World: r3wp

[any end]and [some end]As we don't have warnings, I suggest these 
to produce errors.


- it is impossible to trigger errors every time an infinite loop 
is encountered
- this case has been discussed and the solution was found already

[opt end] ...I suggest to make it produce an error.

- not reasonable, the rule *is* legitimate, as you noted

What you suggest is just a bunch of exceptions in the behaviour, 
which is always bad

You should rather look up how the "infinite loop problem" when using 
ANY and SOME was solved

Here: http://www.rebol.com/r3/docs/concepts/parsing-summary.html#section-11

Input position must change
. And the solution was to invent a new keyword, WHILE. Hm...

I try to keep it simple.

This is much simpler than your exception:

- actually working, your exception does not
- not slowing down parsing

ok :)

As to the WHILE keyword: some people may never use it, being content 
with SOME and AND as they work in R3

I mean SOME and ANY

If you're going to make a better parse, it might be good to take 
into account the efforts that have already started to improve it 
in R3. The R3 improvements need a little work in some cases, but 
the thought that went into the process is quite valuable.


[set end ...] or [copy end ...]: In R3, using any PARSE keyword (not 
just 'end) in a rule for other reasons triggers an error.
>> parse [a] [set end skip]
** Script error: PARSE - command cannot be used as variable: end

[any end] or [some end]: What Ladislav said.


[opt end]: The point of the combination is [opt [end (do something)]]. 
[opt anything] is no more useless than [opt end]. Don't exclude something 
that has no effect just for that reason. Remember, [none] has no 
effect as well, but it's still valuable for making rules more readable.

>> parse/all "/docs/rfq/" "/"
== ["" "docs" "rfq"]

shouldn't this be either
["docs" "rfq"]
or
["" "docs" "rfq" ""]
for the sake of consistency?

yes it should.  :-(

Maxim, you asked for a function version of string parse. Was that 
because of situations like this?

its because I do  A LOT more parsing on strings than on blocks.... 
one of the reasons is that Carl won't allow us to ignore commas in 
string data.  so the vast majority of data which could be read directly 
by rebol is incompatible.   


this is still one of my pet peeves in rebol.  trying to be pure, 
sometimes, just isn't usefull in real life.   PARSE is about managing 
external data, I hate the fact that PARSE isn't trying to be friendly 
with the vast majority of data out there.

Do you mean, you want to be able to parse like this?

>> parse [hello, world!] [2 word!]

its happened often yes.  less lately, since I'm dealing more with 
XML and less with raw data.

more like:

parse load/all "hello, world!" [2 word!]

I have wondered sometimes, what effects it would have, if such commas 
was just ignored. We need commas in numbers, but maybe commas could 
just be ignored beside that.

So do you suggest, load/all "hello, world!" should return [hello 
world!] ? (Notice no comma.)

And without space, comma should maybe split the text? Like:
>> load/all "hello,world!"
== [hello world!]

yes, I always thought that commas should be removed of decimals, 
and simply ignored when loaded.


in mechanical data, commas are never used for decimals.  because 
apps need to load it back and all software accept that dots are for 
decimals and commas for separating lists.   why should REBOL try 
to be different, its just alienating itself from all the data it 
could gobble up effortlessly.

so a comma would be an exact alias for a space, when its not within 
a string.

I almost agree. Here we use comma as decimal point. A few countries 
does that. So all data with money amounts have numbers with comma 
as decimal point here.

But it should be possible to take care of those numbers with commas, 
and ignore all other commas, I think. As we don't ever write
42,
but always something like
42,00

if it's a decimal. So if 42, is seen, it can just be read as integer 
42 and ignore the comma (if using load/all for example).

this is exactly the reason why CSV was it a really fucked up idea. 
comas are there in sentences and multivalued fields, not just numbers.
i always use TSV.

it would make sense to settle w some CSV parser, but not as a default 
behaviour. i was already surprised that parse handles double quotes 
too...

>> parse/all {"asd qwe" zxc} none
== ["asd qwe" " zxc"]

>> parse/all {"asd qwe" zxc} " " 
== ["asd qwe" "zxc"]


it's nice, but it also means there is no plain "split-by-a-character" 
function in rebol, which is just as annoying as missing a join-by-a-character

Although gerneral happy with the default parse seperators find it 
neglegent to not permit overriding them.  and like Max finds, block 
parsing ia a rarity when working with real world data streams.

parse/all string none actually is a CSV loader.  its not a split 
functions.   I always found this dumb, but its the way Carl implemented 
it.

rule, when given as a string is used to specify the CSV separator.

it should also honor line breaks within strings then

eh, didn't know it didn't ! yeah that sucks.

Question on string and block parsing:
   http://stackoverflow.com/questions/6392533

only the second string is checked.
Should be:
['apple some [and string! into ["a" some "b" ]]]

can't post the response

Want me to post it for you?

yep ;-)

Done, thanks.

Parse (YC S11): A Heroku For Mobile Apps.
Great name for a startup...

http://techcrunch.com/2011/08/04/yc-funded-parse-a-heroku-for-mobile-apps/

Can anyone gift me an effecient R2 'parse solution for this problem 
(I am assuming 'parse will out-perform any other approach):

SET UP

I have a huge list of HTML named character entities, eg (a very short 
example):

       named-entities: ["nbsp" "cent" "agrave" "larr" "rarr" "crarr" ] ;; 
       etc
   
And I have some text that may contain some named entities, eg:

       text: "To send, press the ← arrow & then press ↵."
   
PROBLEM

I want to escape every "&" in the text, unless it is part of a named 
entity, eg (assuming a function called escape-amps):
        probe escape-amps text entities

         == "To send, press the ← arrow & then press ↵."
  
TO MAKE IT EASY....

You can can assume a different set up for the named-entities block 
if you want; eg, this may be better for you:

       named-entities: [" " "¢" "à" "←" "→" "↵" 
       ] ;; etc 
   
Any help on this would be much appreciated!

ne: ["←" | "↵"]	; and the rest of the named entities
s: "To send, press the ← arrow & then press ↵."
parse s [
	any [
		to #"&" [ne | skip mark: (insert mark "amp;")]
	]
]
s

== {To send, press the ← arrow & then press ↵.}

It may be faster to drop the & from the entities and change the rule 
to:

any [thru #"&" [ne | mark: (insert mark "amp;")]

That's strange. My 2nd suggestion gives a different result:

ne: ["larr;" | "crarr;"]
s: "To send, press the ← arrow & then press ↵."
parse s [
	any [
		thru #"&" [ne | mark: (insert mark "amp;")]
	]
]
s

== {To send, press the ← arrow & amp;then press ↵.}

Seems like a bug, or am I just tired?

Thanks for the quick contributions, geomol.

I see a different result too -- a space between the "&" and the "amp"

not fluent with html escaping, what's the aim? To replace stand-alone 
#"&" with "&amp"?

also remember - parse does not count spaces in. You are better in 
using parse/all

'I want to escape every "&" in the text, unless it is part of a named 
entity' - just to make sure: if the entity is not in the ENTITIES 
list, like e.g. " and it is encountered in the given TEXT, what 
exactly should happen?

The aim --- Basically, yes, Petr.

Ladislav -- if it is not in the list, then I'd like it escaped, please.

Think of it as a whitelist of ecceptable named entities. All others 
are suspect :)