World: r3wp

forget about the " - " present ...

I always find parsing xmlstrings somewhat fragile ....

I'm not even sure how your parsing works!  But it does :)

the output I presented looks so close to being a rebol object .. 
and then I can use paths to access the data

rule: [
	'getspellingsuggestionsreturn some drugs
	| word! into rule
]

is I think what Gregg wanted to write

Graham - what xml REBOL tool do you use? I might need to parse XML 
stuff soon. In the past I used one tool (don't remember the author), 
which made object from parsed data automatically ...

I tried rebelxml.r but I can't get it to work

it works for simple stuff as in the documentation ... but can't cope 
with the example above.

pr: [any [
  [{<getSpellingSuggestionsReturn xsi:type="soapenc:string">} 

    copy s to "</getSpellingSuggestionsReturn>"
    (insert tail 
drug-names s)
  ]
  |
  skip
  ]
]

usage:

>> drug-names: copy [
]
== []

>> parse/all gxs pr  
 
== true

>> drug-names

== ["Penicillin G" "Penicillin V" "Penicillamine" "Polycillin"]

Sorry about the formatting ... can't cut and paste in AltME on a 
Mac without reformatting.

pr: [any [

  [{<getSpellingSuggestionsReturn xsi:type="soapenc:string">}
 
    copy s to "</getSpellingSuggestionsReturn>"

    (insert tail drug-names )
 
   ]
  |

  skip
  
  ]

]

Are the { } required ?

If it's not fast enough you can speed it up by adding a rule to consume 
the unwanted parts.

I think so because of the "soapenc:string"

gxs is a string of your xml listed above.

I guess it avoids all the other stuff I was doing to force it to 
rebol blocks to allow block parsing :)

I pasted your code here, which loads the block. I guess the XML parser 
produces the output with those values as words.

foreach item load/markup xml [if not tag? item[ print item]]

not parse and not pretty  but  you get the idea

rebelxml works well for most things  ..not just the ones where the 
namespace is in the tag name

http://www.rebol.net/r3blogs/0155.html- if you want some improvements 
to parse, now is the time to ask for them ...

We've hammered out some proposals so far, but we are really interested 
in more ideas, especially if we can make them fit.

So far we have been accepting proposals in these categories:
- Recognition: LIT, NOT, OF, TO and THRU extensions
- Modification: CHANGE, INSERT, REMOVE

- Structural and control flow: FAIL (may not be the final name), 
USE, CHECK (still debate here), REVERSE


There is still some debate even within these proposals (name of FAIL 
for example) and some of them might not make it. Some of the old 
PARSE REPs have been definitively rejected or changed, and some are 
still under debate and won't make it in without a lot more thought.

These changes to PARSE are another example of changes to the R3 core 
happening as a side effect of the new GUI work :)

Lots of good suggestions. I've just re-read Gabriele's Parse REP 
and the ParseProject DocBase article.

CHECK's meaning is like "continue if ...".

Yup. We've been working on the Parse Project article a lot today. 
The last 2 things from the REP that might make it are the THROW and 
INTO-STRING proposals, though both will need some changes first. 
The rest are covered or rejected.

Peter Wood's RETURN proposal is really interesting. I have been thinking 
about how to make a variant of it work.

I'd like to understand Peter Wood's START command a bit better. It's 
not clear to me from the example why it's needed. (or even how the 
example works..)

Peter's example, from the blog:
parse [a b c d] [
    any [
      start (acc: 0)
      |
      set inc integer! (acc: acc + inc)
      |
      end
    ]
  ]

It isn't needed. It's basically the same as if the paren was included 
on its own, but not in the alternation.

That's what I thought. But Peter must have thought it was useful 
for something.

Here's a working version of that example:
parse [1 2 3 4] [
	(acc: 0)
	any [set inc integer! (acc: acc + inc)]
]

I thought maybe the start code is only done when one of the other 
alternates is (about to be) matched.

Perhaps he thought a paren could only follow a rule.

We should wait for Peter's input on that.

I like the RETURN proposal as this:

	RETURN rule


Match the rule and return a copy of the value from the PARSE function. 
Like COPY then BREAK, but without the temporary variable.

BrianH: I posted link to Ladislav's Core proposals. There's parse 
section in there too. You can look at r3-alpha parse group .....

Theye are already covered by the existing proposals.

I vaguely remember suggesting PARSE dialect be extended into parens 
with a few commands. Parens are executed as normal rebol dialect 
(not parse dialected in any way). If I remember correctly, it was 
thought better to keep the parens 'pure' rebol. If that is to be 
maintained, then I think Peter's RETURN command ought to be morphed 
into a parse command, as you suggest above, Brian.

-- ie. that's a good idea.

PARSE actually calls DO for those blocks.

blocks -> parens

Right - so doing an extra bind may slow things down.

More importantly it will override the meaning of the RETURN function 
at a point where you would expect it to work.

Clearly my proposal for START is based on my ignorance and inability 
to search the documents properly :-)

It wouldn't hurt as a form of slef-documenting code, though.

Actually, I think it would hurt (no offence). The word start is a 
common name for parse rules and every keyword we add can't be used 
as a parse rule name. Something to consider when making proposals.

Gabriele's DO command is interesting.

I wonder why it could not become more "functional" and be used after 
the SET command, eg:
	SET result DO integer!

That DO proposal was the first one to be rejected. It will take some 
serious problems with dialecting to get it included.