World: r3wp

but that can just be a static rule outside of compose

More efficiency. I build my charsets once, rather than on every call.

should probably build the rule outside the function as well since 
it only should be rebuilt when the macro list changes

cant say to whitespace

wish you could

tipicaly get around with

that's where my rule got stuck .. on to whitespace

bs: complement ws

any bs

Yeah, I'm changing my code now.

expand-macros: func [data [string!] macros [block!]
    /local ws non-ws macro-rule macro expansion here there
] compose [
    ws: (charset " ^/") non-ws: (complement charset " ^/")
    macro-rule: make block! 2.5 * length? macros
    foreach [macro expansion] macros [
        macro-rule: insert macro-rule
            compose [here: (macro) there: [ws | end] |]
    ]
    macro-rule: head remove back macro-rule
    parse/all data [some [any ws [
        macro-rule (
            macro: copy/part here there

            there: change/part here select/skip macros macro 2 there
        ) :there |
        some non-ws
    ]] to end]
    macro-rule: none
    data
]

See, I don't have to test. Graham has the data, he can test :)

that is the part I can't allways be bothered with either

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