World: r4wp

FORM is used to create a human-friendly format. The description should 
hint for that.

Returns a source format representation of a value.
		value	  [any-type!]
		/only "Exclude outer brackets if value is a block"
		/all  "TBD: Return value in loadable format"
		/flat "Exclude all indentation"
		/part "Limit the length of the result"

Sounds good to me, maybe Ladislav or BrianH would like to be nitpicking 
about it? ;-)

I'm sure they'll help improve things. :-)

FORM:  "Returns a user-friendly string representation of a value."

OR

FORM:  "Returns a value as a user-friendly string."

I prefer the former.

OK.

So this for MOLD?

Returns a source format string representation of a value.

i.e., include "string"

Looks ok to me.

Got it.

Can we use the ROUND doc strings from REBOL, since Ladislav and I 
wrote them outside of RT?

I know ROUND is TBD, and you probably want it native, or you could 
use the old mezz version.

Even though REBOL uses /dup for APPEND and INSERT, would /dupe be 
a better refinement name?

Isn't that to fool someone?

Also, perhaps human-friendly instead of user-friendly?

It can be, but it's also the standard abbreviation for duplicate.

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 ....