World: r3wp

I'm trying to build a string with rebol content inside (also strings). 
And I get into trouble. I think, it's a bug. Try this:
>> s: "^"abc^/def^}ghi^""
== {"abc
def^}ghi"}
>> to-block s
** Syntax Error: Invalid string -- "abc
** Near: (line 1) "abc

This works:
>> s: "^"abc^""
== {"abc"}
>> to-block s
== ["abc"]

so my example above should work too, right?

Looks like to-block isn't noticing the carat:
>> to-block "^{}"
== [""]
>> to-block "^{"
** Syntax Error: Invalid string -- {
** Near: (line 1) {

I don't think, you can have a block with only a '{' inside. REBOL 
will think of it as the start of a string. If you put '{' in between 
"", you don't have to use caret, but you can:
>> to-block "^{^}"
== [""]
>> to-block "{}"
== [""]

I think, my problem start, when I have a newline before a '{':
>> to-block "^"^/{^""
** Syntax Error: Invalid string -- "
** Near: (line 1) "

Because this works:
>> to-block "^"{^""
== ["{"]

I figure, the problem is with strings, not with to-block or any other 
command.

Probably because the caret can be used even in strings and used for 
line termination formatting etc..

I would be ok with reporting this to RAMBO, but would like to be 
sure, it's a bug first. (I don't like too much in RAMBO, if it's 
not a bug anyway.)

Can you give an example of your input and final desired output ?

Input:

Input: "^"^/{^""

That's a string with 4 bytes: A ", then a newline, a { and another 
".
Operation: to-block
Desired output: ["^/{"]

That's a block with a string, that consists of 2 bytes: a newline 
and a {.

If this can be solved, then I can solve my other problems, I think. 
(Same goes with } btw.)

Maybe it's easier to see, if I use binary:
>> b: #{220A7B22}	; That's my input string as binary.
Try these:
>> to-string b
>> to-block b
The last one will fail, but it should give me:
== ["^/{"]

>> s: input
^/{
== {"^^/^{"}
>> to-block s
== ["^/{"]
>> print s
^/{
>> print to-block s

{
>>

Is that what you want?

I guess as soon as you have a newline in your string you should start 
the string with { and not with "

Interesting!

I would just think, that I should write the string like this then:
>> s: {"^/^{"}
but that's not a string for some reason!?

Thanks sqlab. I'll see, if your way can solve my problem, when I 
get home later today.

Why do you think, that this is no string?

>> s: "^/{"
== "^/{"
>> type? s
== string!

It's the molded representation of an internal string

Try it!

You get a new line with { in the beginning. That's REBOL way to tell 
you, you haven't finished your string. Like this:
>> s: {"^/^{"}
{

if I put in a } to finish the string, I get:
{    }
** Syntax Error: Invalid string -- }
** Near: (line 2) }

I see, the problem arises when you type it.

I would initially think, that {"^/^{"} would be a valid string with 
4 chars inside. 2 ", 1 newline and one {, but it isn't.

Did you check if it is the same behaviour when loading from a file?

yes

I have seen different behaviour from typing in the console and loading 
from a file

for example
>> func: [;  []]
** Syntax Error: Missing ] at end-of-script
** Near: (line 1) func: [;  []]
>>

eFishAnt, yes that's a string. I'm trying to build REBOL content 
within a string, so I have to figure out how to type strings within 
strings.

maybe you can use 
inp:  ["^/{"]
append your-string   inp

Seems not to work

Not really. I start with a string:
output: make string! 10000

then I go into a parse, where I build REBOL content within my output 
string. Sometimes I have to append a string (as a string) to output, 
and it fails, when I have newlines and { like characters.

I can't start with a block, because I can't append the start of a 
block to a block. I have to append a whole block to a block, and 
I don't know the full content of the block. So I start with a string.

What do you mean with appending the start of a block to a block?

appending a [

You can with '[

like:
>> blk: []
== []
>> append blk '[

No, I can't. Try it!

I have to check in a script I did short before and I thought I did 
something similar

>> append [] to-lit-word "["
== ['[]

append [] to-word "["
== [[]

t: append [] to-lit-word "["
== ['[]
>> reduce t
== [[]
>> or compose etc

Oki doki! :-)

I then just save my result to disk (because I can't use it directly, 
as those [ and ] are words (and not a real block). After reload of 
the result from disk, it should be real REBOL, right? Would be great, 
if I could build in a block and not a string.

Yes, that's how I try to compose some rules.

load mold works too
>> t: rejoin [ [] to-word "[" to-word "]"]
== [[ ]]
>>  load mold  t
== [[]]
>> type? first load mold t
== block!
>>

Ok, got it. Thanks!

@sqlab I've now implemented the block method instead of the string 
method, when I'm building REBOL syntax, and it works very well. Now 
I should be able to finish the first pass of my document format very 
soon, so I'm happy! :-)

Just one comment

You say, you do not know the content of the block you want to insert.

If you keep the reference to the block, you can always insert later 
into the block.

>> outer: append/only  [] internal: []
== [[]]
>> insert internal "test"
== []
>> outer
== [["test"]]

Yes, I'm aware of that REBOL trick. :-) It's because, what I'm parsing 
might be blocks within blocks in a recursive way.

XML is an example of such a structure. If I see a start-tag, I insert 
the beginning of a block in my result, then parse further in the 
document finding content and other start-tags and so on. The best 
way is to produce the output in a seriel manner from beginning to 
end, like I parse the input.

You can use another block as a stack of  blocks references :

- When you meet a new tag, push the current block reference on the 
stack (insert tail) and make current ref to a new block.

- When you meet a close tag, pop the last reference from the stack 
in the current ref  (pick last, and remove back tail)

Just a word of warning -- use the latest betas for any significantly 
nested block structure.

As I found out the hard way recently, the production releases (at 
least under windows) behave erratically when stressed with a few 
hundred nested blocks. Some problem with garbage collection, apparently.