World: r4wp

STRICT-EQUAL? delegates to the datatype. Should the doc string just 
say "strictly equal" in it, or should it be more like R2? i.e., there 
may be more going on, unless you have a behavior locked down for 
it.

BTW, even though I'm not ready to write deep .reds code, it's very 
enjoyable to have a reason to go through the code now. It's very 
nice.

STRICT-EQUAL?: I prefer the R2 doc-string, it is more helpful.

If the model for == is that all datatypes should use the ALL [type 
= ...  value =] tests, we can just say...OK, you beat me. :-)

:-)

As several followers have requested some docs for the internal API, 
I will see this week, if I can find a few hours to write a basic 
one, just to get you started.

It may save you answering a lot of  my questions. :-)

As long as you have some basic knowledge of Red/System, with the 
docs, writing new natives or datatypes, should be pretty straightforward.

Gregg: I hope so. :-)

Things are clearly laid out, but slot order and the stack are important 
to understand.

Also the series! memory model (block! vs string!) is a fundamental 
part to understand.

Looking at %runtime/datatypes/structure.reds is a good help.

(structures.reds)

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? ;-)