World: r3wp

Well, if you want exceptions, you gotta code them in. In this case, 
before the block of your markup rules, as an alternate.

Like this (at the beginning of the any block):
    ["**" any "*"] |

(Be back, off to a class)

Well, I got things behaving by specifying " " at the beginning. It's 
a start.

ah the 2:46:49 post avoided that

with the opt[] block if what followed wan not a well formed marked 
up string

hm. Now I just need to figure out how to allow markup at the start 
of a line. I'll need to look at your code back there.

yay, got it working. It's ugly, but I got it working.

I'm not seeing a good solution to this at the moment, so I thought 
I would ask for help.  I'm working with parse and I want to create 
a new set of grammar rules dynamically based on the inputed grammar. 
 The simplest example I can present is starting with the following 
rule

	b: [19]

and in the end I want to have this.
        w: {}
	newb: [(append w "the b value is 19") 19 (append w newline)]


While I can insert an APPEND that doesn't contain values from the 
original rules into the block very easily, 

insert tail newb [(append w newline)]


I'm not sure of a way to insert a parenthesized APPEND with a string 
that contains info about the block.  I hope this is clear (or even 
possible), but please ask me questions if it is not.

I suppose the question I'm asking is there a way to force the arguments 
of an expression to evaluate without actually evaluating the expression. 
 Taking the aboe example

a: join "the b value is " first b

insert head newb [(append w a)]

where I want to evaluate 'a while ending up with the expression:

insert head newb [(append w "the b value is 19")]


This seems contrary to the nature of first order functions, but I 
just wanted to check.

Excuse me, first - class functions

interesting questions, unfortunately not having time to answer any

a: 19 append/only [] to-paren reduce ['append  'w join "the b value 
is " a]

or

a: 19 append/only [] to-paren compose [append w (join "the b value 
is " a)]

You _just_ beat me to it ...

;-)

Forgot to use /only on first try

Thank you Romano and Ingo

How do you parse for a particular integer value ?

parse [ -1 ] [ integer! ]

but I want

parse [ 1] to fail ...

you can do it as a string:
>> parse form [-1] ["-1"]
== true
>> parse form [1] ["-1"]
== false

but as a block... hmmm

>> parse [-1] [1 1 -1]
== true
>> parse [1] [1 1 -1]
== false

lol
How did you do that? Why does it work? :-)

ah of course. Number of instances (1 1 means exactly 1, right?).

tricky :)

>> parse [1 1 1 1] [1 4 1]
== true
>> parse [1 1 1 1] [1 3 1]
== false

Putting numbers in the rule block indicates number of something. 
So [1 4 1] means 1 to 4 times 1.

Easier to see this way:
>> parse [a a a a] [1 4 'a]
== true
>> parse [a a a a] [1 3 'a]
== false

Shouldn't?
parse [1][1] ;== true

So if you wanna check for exactly one time -1, you write [1 1 -1].

Jaime, when you put a number in, it's the start of a min/max indicator. 
You never type max or what to search for, so it fails.

well, apparently numbers are not literals when parsing ...

Same as
>> parse [1] []
== false

must add this to the wikibook :)

>> parse [-1 -1] [2 -1]
== false
>> parse [-1 -1] [2 2 -1]
== true

The first doesn't give meaning to parse, because a number means a 
min, so parse look for a max, and then the data.

A bit consusing. Maybe we should express ranges differently.

Maybe with an issue.

#1-4

Then that needs to be parsed too.
>> i: #1-4
== #1-4
>> i/1
== #"1"
>> i/2
== #"-"
>> i/3
== #"4"
But I could have written:
#001-00004

>> parse [1 1 1] [001 00004 1]
== true

I think, Carl likes to keep it short. :-)

What about a pair for ranges.

Yes, that is better.

literals can help sometimes. But then the problem becomes that pair 
literal could have the same problem than number literal has now.

But then this will give problem:
>> parse [1x2] [1x2]
== true

Yep.

But parse [1][1] ;== false (seems odd).

Maybe rebol needs a literal representation for ranges.

yes, but if you changed min/max to a pair, then
parse [1x2][1x2]
wourld fail.

I understand. I just suggesting that the parse dialect could be further 
optimized.