World: r4wp

Clearly. From a testing and coverage perspective, it would be great 
to have a matrix (and an easy way to generate it) to see how complete 
each type is, or make sure you have everything in place when building 
a new type.

That is what I was asking for a few months ago from contributors.

Red runtime code can be easily parsed to extract those information.

Let me finish my pass on boot doc strings, and then I may look at 
that.

Peter has already started something in Red/docs/generate-reds-api.r, 
but it might be just for extracting doc-strings.

OK.

SAME? is a tricky one. I will make it very basic for now, and we 
can fix it when more accuracy and details are needed.

I don't know how Ladislav's identity article applies, since R2 and 
R3 differ as well.

SAME? is not implemented yet, we need first a matrix of datatypes 
and consider each case one by one, then implement it.

Yes - Red/docs/generate-reds-api.r just extract docstrings ... but 
it shouldn't be hard to generate the datatype matrix.

The dataype comparison matrix is on my todo list but I haven't found 
time to start on it yet.

7000 hits so far on red-lang.org since the new blog entry. The Reddit 
wave has been the biggest I've seen since the site is online. We'll 
need to particulary target Reddit for future Red communication (the 
current one happened by accident, but it's still instructive).

Doc, do you want any TBD marks for things that aren't implemented 
yet? e.g. /all and /header in LOAD?

Or should I put in stubs based on how they work in REBOL.

TBD marks are more helpful for now, you can put stubs from REBOL 
in comments, so when implemented, I would just uncomment it.

So you want:

; TBD: "Include Red header as a loaded value"

Not

TBD: Include Red header as a loaded value

Correct?

Right, that's a good solution.

Got it.

Sorry, I mean otherwise.

Ummm, which one?

Including a TBD: header in the doc-string is better.

Ah, OK.

I have extended FUNCTION to collect iterator counter words. Will 
push the changes tonight:

red>> f: function [] [repeat i 5 [print i]]
== func [/local i][repeat i 5 [print i]]
red>> f
1
2
3
4
5
red>> i
*** Error: word has no value!

Doc, please be sure to leave something for old REBOLers to complain 
about, or they won't be happy. ;-)

I'll try, but no promises. ;-)

:-)

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

/ALL is TBD.

Just from quick tests and a glance at code.

What is the latest consensus for that naming in R3? I like the "loadable" 
format expression but I'm not sure it is the best one.

No: without /ALL: "source" format, /ALL: "loadable" format?

No => So

For FORM I have:
	"Returns a string representation of a value."
and for MOLD:
	"Returns a loadable string representation of a value."

Ah, OK.

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?