World: r3wp

In your version, the syntax error was at load time, before the attempt 
was called.

This isn't good for dynamic data.  If something is populated dynamically 
then would have to account for the spaces and check the dynamic data.

>> mold [ < ]
== "[<]"

Yeah but that isn't acceptable for me.

I would classify that as a workaround and the problem still to be 
a bug.

I said it was unfortunate :(

hehe

It used to be the case for to-file "" too.

ahhh well hopefully we can get it fixed.

>> [>]
== [>]
Not a problem for <

Yeah just the one needs fixed then.

>> [<
[    ]
== [<
]

yeah that is why I need the mold to trim the lines from something 
like that.

>> [ < ]
== [<]
>> new-line [ < ] true
== [
    <
]

Same value, different display.

>> c
== "[<]"
>> d: []
== []
>> append d to-word c
== [[<]]
>> e: first d
== [<]

>> mold new-line [< ] true
== "[^/    <^/]"

It's a little longer, but at least it will load and have the same 
value.

On this I tried    a: pick first system/words 122   (umm 122 will 
vary of course)  
b: make binary! 0     save/all b a   c: to block!  b

>> new-line load mold new-line [< ] true false
== [<
]
>> mold new-line load mold new-line [< ] true false
== "[<^/]"

I'm staying away from load

just for my purposes anyway

As long as you control the save, load is all right

I think appending might be my solution for my purposes.

I can't have the newline in the block.

Right, you read/lines.

Thanks guys, I think I got a solution.

Cool.

Cool;  A little background for Brian's sake.  I bumped into this 
trying to move my LOCATE routine to TRETBASE so I was using system/words 
as a source for testing.  Didn't make it past entry 122  <   to lit-word! 
 didn't make it past 111  '/   kakks too.

If you think that's bad, look at this:
>> [<]>]
== [<]>]

hehe I'm dizzy

>> length? [<][>]
== 1

Nice tags.   :)   Leave it to Mr Hawley to get the crux

Sees it as a tag

Nasty, eh? :)

yes ;-)

I think I'm on to something in REBOL and I want some input on this. 
 If I define a block in a function such as:


my-func: func [data /local blk][blk: copy []  append blk data print 
blk clear blk]


Now even though blk is cleared will the memory still be allocated 
to the size the blk expanded to accomodate the data argument?


If so, instead of clearing blk would it be better to unset or set 
blk as none at the completion of the function?  I'm just guess that 
REBOL's garbage collector wouldn't want to clear the memory allocation 
of blk since it doesn't seem efficient to do so.

That kind of thing was the original motivation for the ALSO function. 
Try this:

my-func: func [data /local blk][blk: copy []  append blk data print 
blk also blk blk: none]

forgot what the source of also looked like.  I might need to load 
2.7.6

So is the fix really to just set blk to none?

also: func [
    {Returns the first value, but also evaluates the second.}
    value1 [any-type!]
    value2 [any-type!]
][
    get/any 'value1
]

Yes, that is the fix. You should also set data to none.

Yeah good point.  So we really don't need ALSO to free the memory 
then right?

ALSO is to let you return a value assigned to a variable, and still 
be able to unset the variable.

Thanks Brian.

Why was ALSO created?

For cleanup.

I don't fully comprehend the also function.  I know it is getting 
the value but why pass it twice?

so really you would always want the second value to be word: none 
correct?

It's an evaluation trick. It evaluates two expressions and returns 
the value of the first. You can do your cleanup in the second expression. 
If your cleanup is more complex, put it in a paren. The value returned 
by the second expression is taken and ignored.