World: r4wp

I still prefer having FUNCTION take care of it and using simple word! 
values, else it looks odd and misleading (i: 5 looks like one expression, 
while it is two expressions in fact).

Same for i: [1 2 3].

Nice trick anyway. ;-)

I know, but I still think it's a fairly good compromise

Have you tried it in interpreter?

Yes, haven't checked the compiler

REBOL uses a dot when it's a full sentence, which is usually the 
case for the function description, but not for parameter descriptions

Is it correct to state that FUNCTION automatically localizes all 
refinement, get-word, and set-word values found in the function body? 
And that is all that makes it cifferent than FUNC?

If so, since I don't know, why not just set-words?

Or, rather, why all word types except word?

Have you tested that? As far as I know, it only adds set-words to 
the arguments and refinements

I haven't. I looked at the code.

Will have to wait until Doc rises again :-)

Shouldn't you be sleeping too? ;-)

Erm, yes

A lot of doc strings talk about "evaluating", which is a long word. 
Is it less clear, or less correct, so use "do" instead, at least 
in most cases?

function localizes only set-words. (refinements are local by default)

Gregg: only set-words are localized. What you saw in _function/collect-words 
is the the conversion of spec block elements to words for the ignore 
list. The collection of words from body block happens in collect-deep.

Thanks for clarifying Doc.

In %boot.red, SET's word arg is typed as any-word!, but it accepts 
a block of words. Should the type be [any-word! any-block!] ?

Right, but just block!.

OK.

Do you think we should allow paren! too?

R3 doesn't allow it.

I don't think we need to, but Ladislav or Brian may have thoughts 
on it.

...or Andreas, or Kaj, or the other Brian... :-)

I don't see any good use for it either.

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.