World: r4wp

I'll let Doc say if it's for humans for users.

ROUND: a bit premature, we still don't have a float type in Red.

Or you mean doc-string: sure you can.

Forth and RPL (I've done a lot of code in RPL long time ago) use 
DUP as abbreviation for "duplicate".

I see no need to make arbitrary changes from Rebol unless we have 
something to gain.

(Bookmark it, you might throw at me that quote someday in the future 
after I make a purely subjective and arbitrary change from Rebol. 
;-))

version.r seems to be missing from the repository

https://github.com/dockimbel/Red/blob/master/version.r

Sorry, it's probably missing from my build recipe

Has anyone tried APPEND/DUP?

red>> s: copy ""
== ""
red>>
red>> append/dup s #" " 10
== 10
red>> s
== " "
red>> head s
== " "

red>> s: copy ""
== ""
red>> append/dup s #"1" 10
== "1111111111"
red>> length? s 
== 10
red>> s
== "1111111111"

There aren't any tests of refinements to append yet. I'll start an 
append-tests.red file for them inlcuding your 10 spaces test Gregg.

It appears that the problem is only appending spaces to a null string. 
it seems okay appending 10 spaces to a space.

red>> length? append/dup " " #" " 10
== 11

The issue seems to be with the console as the tests work in both 
the compiler and the interpreter.

The issue seems to be with the console as the tests work in both 
the compiler and the interpreter.

Sorry for the double posting.

Actually, Gregg's test works under OS X:

Schulz:Red peter$ ./console

-=== Red Console alpha version ===-
(only Latin-1 input supported)

red>> s: copy ""
== ""
red>> append/dup s #" " 10
== "          "
red>> length? s
== 10

works under WinXP too
red>> append/dup s: copy "" #" " 10
== "          "
red>> length? s
== 10
red>>

Works here from Win7 too.

'For MOLD/ALL, are you calling it "serialized" format in Red? And 
I assume that's a TBD at this point.' Gregg, suggested reading:

http://en.wikibooks.org/wiki/REBOL_Programming/mold

'No: without /ALL: "source" format, /ALL: "loadable" format?' - /ALL 
has a totally different meaning for LOAD than for MOLD, BTW

See also http://issue.cc/r3/1955

Your "construction syntax" is a bit long but accurate and meaningful 
naming.

Not exactly mine (to not take credits for something I did not invent), 
but I am promoting it is meaningful.

err: "as meaningful"

copying:

http://issue.cc/r3/2006

Saw it in R3 group. It's a nice trick, but don't you think that the 
setword used in such place might confuse readers? (at first look, 
I read [i: 100]...)

We shall se what the preferences are...

(At least I hope so)

Using [i:] instead of i: would remove the possible confusion, but 
it looks a bit inelegant.

Wouldn't it look confusing, if one would like (not sure anyone would 
to :-) to use something like:

 repeat i: j: 10 [print [i j]]

confusing? hmm, you can use parentheses to make it more readable:

repeat i: (j: 10) [...]

if you prefer

that's right ... I would understand the code even without parentheses, 
I think ....

Append/dup, thanks all for testing. Not sure how I could have broken 
anything by just adding doc strings to boot.red, but it's not just 
spaces for me here (Win7):

red>> s: copy ""
== ""
red>> append/dup s #"1" 10
== 10
red>> s
== "1"
red>> length? s
== 1

I will have to test more. If I just paste the original append source 
into the console (i.e. all doc strings removed), calling append then 
crashes.

If I rebuild the console with the version of append that has no doc 
strings, it works fine. Interesting.

It's having the doc string on the /dup refinement itself that causes 
it.

Take that out and it works fine.

It looks like that 's the case for all refinements that take an arg. 
If you have a doc string before the arg, it causes the arg to be 
ignored.

Can someone please confirm?

Testing with a string! between a refinement and its argument, I get 
odd results (but no crashes so far). Definitely a bug.

Do you want a bug report, or have you logged it yourself?

We need a bugtracker entry for this one, if you're on it, please 
add it.

red>> get 'x
red>> type? get 'x
==
red>> print type? get 'x
unset

The second result is the one in question.

Odd...please add it to the bugtracker.

Hmm, I get correct result here:

red>> get 'x
red>> type? get 'x
== unset!

Probably an interference from doc-strings like for APPEND.

Could be.

After pulling your doc-strings locally and recompiling the console 
I get the same output as you.

I need to fix that issue asap, before getting flooded with new tickets. 
:)