World: r4wp

once I figure out al these context issues

Robert, do you guys have other schemes written so we don't duplicate 
?

rebol [
	type: 'module
	name: 'test
	version: 0.0.1
	notes: {
		to illustrate a a context issue.

  free variables defined inside a module are supposed to be "global" 
  to the module only.
		See http://www.rebol.net/r3blogs/0048.html
	}
]

do test: func [ ][
	set 'new-word none
]

>> do %test-module.r
Module: "Untitled" Version: 0.0.1 Date: none
** Script error: new-word word is not bound to a context

** Where: set function! do -apply- make catch either either -apply- 
do
** Near: set 'new-word none

this works though

do test: func [ /local new-word ][
	set 'new-word none
]

this also fails

do test: funct [ ][
	set 'new-word none
]

Thanks Graham, that seems to be the correct behavior. We should adapt 
those for the test suite.

The design of the module system has changed since that blog. In order 
for free variables to be defined at the module level, they need to 
be set at the top level with set-words like an object. Also, FUNCT 
only collects set-words, so it's correct that in your last example 
it doesn't treat iot as a local.

An isolated module acts like the blog suggests though.

I think we'll really need coherent documentation for the intended 
status quo of the module system soon.

This is a trifle frustrating that the docs are not being updated

Yes. Actually, there's a pull request that represents the current 
intended design of the module system ( https://github.com/rebol/r3/pull/40
). And I'm working on a set of tests that should help document it 
as well.

Docs not being updated? The user-level docs were never written. I 
still need to update the guru docs. It's worse that you thought.

that -> than

That pull request unfortunately only covers a teensy tiny bit.

Nope, it just fixes the last non-working part.

But without it you don't have the intended behavior.

For one aspect.

The module system could be a deciding feature pro R3. But we really 
need to get started on docs for that to become true.

The module system was almost complete in implementation with the 
last closed-source release, needing only the fixes we (and I mean 
me and you, Andreas) did in the first week of the open source release. 
We have only been waiting for Carl to add that pull request to get 
the current design working as intended, though that request doesn't 
only apply to modules in particular, but to scripts in general. Once 
it is accepted, I need to do another round of optimization, but the 
external effects are set already.

So we are at the stage of writing docs and tests.

The only reason the user-level docs aren't yet written is because 
I am really bad at writing user-level docs of any kind. I was hoping 
that I could write some guru-level docs and then let someone read 
them and write something user-level.

As for that blog, the behavior described there has some practical 
problems. There is nothing in the code itself (I mean the example 
code in the blog, not the implementation code) to indicate that 'last-stock 
is a free variable, but 'if and 'not are not - they are all words 
not declared at the top level of the module (by using them as set-words, 
like in an object) or elsewhere in the code. This means that if you 
want it to have 'last-stock be made local to a module, you would 
have to make 'if and 'not local as well. That works if lib words 
can only be set once, but not if they can be reset, since changes 
wouldn't propagate to the other modules or user scripts (since those 
values are copied to words in other contexts).


We determined that the behavior described in that blog could be useful 
enough to be worth supporting, but had some nasty side effects that 
made it not be what we wanted to do by default. That is why we made 
it an option, in particular the isolate option. If you specify the 
isolate option, your module acts like it does in the blog, and this 
has the effect of isolating your module from all external changes 
to the lib context.

what isolate option?

rebol [type: module options: [isolate]] your script

Carl decided that the best way to make extensible options was to 
put the flag-like ones in an options block. That makes them extensible 
without bloating your header.

Another of the already-implemented options is private. The isolate 
option affects importing, the private option affects exporting.

You can do both of course.

There is also a content option (it acts like content: true from R2), 
and a compress option (for scripts that are stored compressed, and 
automatically decompress on load).

The content and compress options don't require type: module - they 
work on regular scripts too.

Scripts can also be checked against checksums, and can be limited 
to a length, but those aren't flags so they need their own header 
words.

Great to know who the caretakers of R3 source are.  Thanks for your 
work all six of you.  :)

The six people named are caretakers of the R3 bug reporting system. 
At the moment, Carl is the only code caretaker.

Close, but not exact, I would say. Other people take care of r3 code 
as well.

A picture is worth a thousand words:

https://github.com/rebol/r3/network

Btw, "Reviewed" has generally meant that someone has gone over the 
ticket and not immediately found a good reason to dismiss it, and 
that we haven't found a problem yet. It is not an indication that 
the ticket should be implemented - we frequently have competing contradictory 
tickets. So it sometimes means that more debate is needed before 
we can accept or reject it. On the other hand, it sometimes means 
that we haven't gotten around to it yet. Nonetheless, some reviewed 
tickets will eventually be rejected. Carl and I were the reviewers 
for the most part, except in the case of bugs that needed some domain-specific 
knowledge, like the math bugs we referred to Ladislav.

In general, when there are competing proposals and we finally pick 
and implement one, we dismiss the competing ones, even if they were 
"reviewed" before.

do we have a state, awaiting implementation?

Basically, "reviewed" with a consensus. No specific marker. We need 
to have the people who are familiar with the arguments go through 
the tickets that aren't still under debate and implement them.

Just that I had a proposal which was accepted and marked as built 
and then you reviewed and found it wasn't built

So, how many of those are hanging around?

We might want to rethink that now that Carl and I aren't the only 
ones implementing things :)

I haven't had a chance to go over the remaining tickets yet. And 
there are some that weren't implemented yet because Carl didn't want 
to, but hadn't yet convinced the rest of us as to why. Those might 
be dismissed if we get a good argument against them, which we can 
do in some cases ourselves now that we can see the native source.

so we need a state of confirmed built

That was the "tested" state.

And we need to go through the old previously implemented but now 
invalid tickets, to mark them as such so we don't have bad tests 
added for them.

For some of the early tickets, more thought and experience caused 
us to change our minds later on.

We used the "tested" state for confirmed built. The "complete" state 
was supposed to be for when we added a test for it to the standard 
test suite, but we were not as consistent about that.

Graham, was that proposal state change recent? Was it changed to 
"pending"? We've had a bit of a definitional problem with the "built" 
state lately. Until we actually get official builds, with version 
numbers, we don't really have a defined "built" state. We need a 
state for "implemented and accepted as a pull request into Carl's 
repo, but not in an official build yet", but we've just been callung 
that "pending" for short.

I think using "built" to mark things once they get accepted is fine 
(much better than "pending"), but we then lack a state to describe 
things which have been submitted as pull request but have not yet 
been declined or accepted.