World: r3wp

LOL ...

When it's my data, I test it myself. After the major logc bugs are 
worked out in my head of course...

REBOL catches spelling errors (logc -> logic).

Have you guys made any submissions to RT for parse improvements for 
R3?

Any further submissions ie.

RT can just use the pending suggeations from before R3

Gabriele and I have worked extensively on such submissions.

Ok, Brian, this one seems to work :)

Hmm.  Another problem.  If the macro expansion contains newline characters 
ie. "^/", the returned text has "^/" in it

ros {ROS: ^/Gen: wt. stable,no fever,chills or night sweats^/CVS: 
neg cp, sob, pnd, orthopnea or dyspnea on exertion^/GI: neg constipation, 
bright red blood per rectum, or melena

I guess I need to form it before I add them to the macros block.

Trim it.

the above macro is supposed to expand into a multiline statement.

Then it is a good thing that the ^/ is in the expansion.

No, as it ends up on screen showing ^/ instead of a visual newline.

Are they writing ^/ in the expansion text source data to indicate 
a newline?

Yes.  So, somehow I need to force the area field to recognise them 
as newlines and reformat the screen.

They're using ^/ as the macros are being read in from a text file 
using read/lines

When you read the macro data, do this to the expansions:
replace/all expansion "^^/" "^/"

so, read/lines is escaping the ^/ ?

No, it isn't. You have to yourself. Can you save the macro data in 
REBOL data format?

I guess so, but I want to make it easy for the users ...

but that works now :)

Thanks for the help guys

how "local" are variables that are set during a parse? I was looking 
at Geomol's postscript.r and looked at:

coords: [err:
	(pos: none) [set pos pair! | set x number! set y number!] (
		either pos [
			append output compose [(pos/x) " " (pos/y) " lineto^/"]
		][
			append output compose [(x) " " (y) " lineto^/"]
		]
	)
]

but I can't get 'pos set in my own code in the () block after the 
parse block where 'pos is set.

that means it does get set inside the parse block, but it's set to 
none after the parse block again.

Is your code in the second parens actually ever executing ?

yes, I try to print the variable and it just returns none.

Mmm let me make a few tests.

actually, there is a difference between my code and this, which may 
be causing it:


I need to loop the block with 'any. I suspect the contents is lost 
after the first run.

because you set it to none in the first parens

Yes the rule can only fail after the first parens.

oldes: it makes no difference whether the first parens is left out 
or not

And to answer your question, the variables are just regular rebol 
words, so they are as local as you make them.

and how looks the code you parse?

if the parse is inside function and you set pos in the function as 
a local - it will be local

I'm parsing:

[image "String" image-word [action block]]

where 'image is always first and the remaining items may come in 
random order

there is no pair and no numbers - the pos must be none

oldes, my code is different from his. I used his as it's structurally 
similar to mine

and what exactly do you want?

I want to assign a variable to each element so I can process them 
later

so for the block above it would assing what?

the block is stored in 'attr.

parse attr [

  (txt: 123 print txt) 'image any [set txt string! (print txt) | set 
  img word! | set action block!] (print txt) | 'face
]

gives:

123
search
none
== true

argh... forgot to show you attr

attr: [image test-image "Search" [print "test"]]

Don't you want to use rather:

parse/all attr [(txt: 123 print txt) 'image opt [set txt string! 
(print txt)] opt [ set img word!] opt [ set action block! (print 
txt)] (print txt) | 'face]

it seems the variable is stored in the last iteration, so it's definitely 
lost after one loop.

Doesn't Henrik want to be able to process the attributes in any order 
?