World: r4wp

OK.

Doc string question. Example:

if:	make native! [
	[
		"If	condition is TRUE, evaluate	block; else	return NONE."
		cond	 [any-type!] "Test condition."
		then-blk [block!] "Block to	evaluate."
	]
	#get-definition	NAT_IF
]


1) For simple funcs, do we want to include doc strings for params 
that seem self-explanatory?


2) Do we want to include periods at the end of param doc strings? 
REBOL includes them for function doc strings, but not param doc strings 
(it seems).

A simple suggestion: instead of "is TRUE"  I would suggest to use 
"is true" meaning anything distinct from FALSE and NONE.

1) Probably not.


2) No need to add dots everywhere, we can add them when rendering 
the doc-strings where adequate.

is true
 +1

Right, what I meant was that LOOP, being dialected, could easily 
localize the counter word.

Indeed, and it can already be done easily:

f: function [] [repeat i: 5 [print i]]
f

f: function [] [foreach i: [1 2 3] [print i]]
f

Gregg, thanks for working on the doc strings

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.