World: r3wp

Lazy: Let's assume I have a quite complex evaluation graph with 100 
input parameters. Think of it like an Excel spreadsheet. Now what 
I want is that if one parameter changes, that all dependent parts 
are re-evaluated. Like Excel does it.

Maybe a constraint solver is  the better word

The problem with Excel is that you can create complex calculations 
quite easy but if you are not the author, doing a reverse engineering 
is tedious. Having an excel like model available on the language 
level would IMO be very nice.

i can work on it, what form of evaluation graph do you expect ?

Geomol, I'm not saying that what you want can't be done, I'm saying 
that you would be creating a new context type, not a new word type. 
The type of a word doesn't in any way affect the behavior of value 
slots that the word might refer to, but the context type does.


However, I don't think that a new context type would be needed here, 
because the object! context is shared by default. The only thing 
you are affecting is whether prototype fields would be shared amongst 
derived objects, or copied. You could easily implement this kind 
of sharing using a mezzanine like FUNCT (not FUNCT, but another mezzanine 
with a similar implementation). There would be no performance degradation 
on use of the shared words, and only minimal at creation time. The 
reslting code would be semantically equivalent to the R2-style shared 
inner object model, but the code wold be simpler.

For that matter, FUNCT/with implements something similar to what 
you request, but with functions instead of derived objects.

BrianH: in regards to #1228 - how can you access unnamed module by 
path notation? I mean - normally you can access unexported values 
by module-name/value, no?

(I probably need to start using them in real-life :-)

You need to import a module explicitly using IMPORT if you want to 
use path notation.

For the most part, you don't access unexported module variables, 
and don't use path notation. Minimal programmer overhead.

I had to do some interesting tricks to get mixins to work, but they 
do work well.

Can I have protected module members? I mean - non accessible by path 
notation?

PROTECT/hide, or inner contexts.

Modules are for code organization, not information hiding. You generally 
protect stuff using PROTECT - it works better that way.

hmm, protect/hide - where do I call it from? At what stage? What 
about having header options - exports, imports, protects? :-)

Well, I probably think about them way too much as about objects. 
OTOH - I might have some module, but I want to hide my internals 
... kind of DLL aproach - you only provide docs with the accessible 
API and the rest should be hidden and even maybe signed ...

PROTECT/hide is called in your code, generally in the code block 
of the module. It blocks binding. Once all of the code that you want 
to have access to the word has already bound to it, PROTECT/hide 
will prevent any future code from binding to it. You can't do traditional 
OOL protection because of the direct binding of REBOL, but PROTECT 
works pretty well (aside from stuff still in CureCode).

In general, R3 assumes that the developer who is creating the script 
is not an idiot, and knows what they want to do. If they want to 
lock things down then there are ways to enable that safely. Otherwise, 
it's as open as you want it to be. PITL doesn''t require that the 
system hide everything, just thaat it be possible to organize large 
systems. Protect what you need to.

OK, so what is the possibility for developer to provide users with 
some secure = signed module, with protected internals and only providing 
users with exported API? Do I have to use extensions for that, and 
mangle my code somehow? Calling proted/hide in user app does not 
help module author, if he/she does not wish to release his code. 
My questions are theoretical - I will probably never write any such 
stuff, but I would like to imagine, how some business entinty could 
aproach this ...

Signing a module only gives a user someone to blame if things go 
wrong - it isn't real protection. But I agree, code signing would 
be nice, especially for extensions since you can't just read the 
code very easily. The checksum support works for verifying the code 
matches what you expect though.


The module system is designed with security in mind, not closing 
the source. If you want closed source make an extension, or encrypt 
your REBOL source (like R2 encapping), or build your own host program 
(the R3 version of encapping), or download the source from a secure 
server and protect the words that refer to it so you can't get at 
it through reflection at runtime. REBOL still isn't compiled, sorry.

would creating a module within an extension's mezz code section effectively 
count as a closed module? is it even possible?

(sorry for not joining discussion earlier... I've been offline for 
almost a week due to my DSL modem going bust)

An extension's mezz code is itself a module, and its source is as 
closed as you can make any source that is embedded in native code.

so since we export some words and extension mezz are essentially 
unnamed modules... their content really is hidden and can't be extracted 
  :-)

although I guess scanning the extension with a hex editor will reveal 
the code inside!?

Just read a R3 blog post about the future of the alias cmd in R3. 
Someone commented that we should see the state of the art : http://www.extjs.com/products/gxt/
 not too foolish but can we do something similar with R2 or R3 ? 
That's where I would like  to go with R2 and R3 ...

The extension mezz are not just unnamed modules, they are real modules 
that follow the same rules as regular modules, including naming and 
isolation. IMPORT doesn't know the difference between a module and 
an extension.

You are right about a hex editor seeing the REBOL source though, 
unless you do something weird to generate the source instead of referencing 
a literal string. However, remember that the code in memory is the 
result of executing the code in the module source, generating the 
in-memory data. That generation can be really elaborate if you like.

last two - three weeks are really slow in regards to R3 development 
... unless Carl is doing something in the background ...

Gerard - I think that in regards to View, we might see some interesting 
things. VID3 is going to be much more flexible, than VID2. It should 
(and hopefully will) provoke skin and widget authors to come-up with 
some more professional looks. We can try to mimick ExtJS for e.g. 
Another possibility is VID3 "compiler", so that your VID3 source 
gets "compiled" to ExtJS or some other widgets, running in your browser 
.... it is very preliminary to say, where the future leads us ...

Seems links to demos on that page are dead.

September plan posted - http://www.rebol.com/article/0426.html

hmm, actually does not sound like a plan ...

yeah, what about the sound port ?? ;-)

look at detailed beta plan - it is just list of things to do. It 
seems Carl is not sure about adding sound device (for the beta)

i wasn't serious...

But rebolek might be serious :-)

the list is sometimes strange - why 'replace has high priority, but 
other imo more important stuff has medium or low?

I think you are underestimating how badly REPLACE sucks. I wrote 
it, so I know it is as good as you are going to get in mezzanine. 
And it's a widely used and reviled function.

I expected such a comment on your part :-)

well, everything is important. But how much speed-up do we get via 
new replace? How often is that used in our code? :-)

I made it as best I could. It needs to be native.

I agree about the need for replace being a native. I would prefer 
emphasis on other areas though, e.g. on parse enhancements :-)

But - according to the list, it is hopefully being adressed too ...

If it didn't suck, it would be used a *lot*. This would be almost 
as much of a speedup as REDUCE/into and COMPOSE/into.

Parse enhancements are hard - have you seen that list?

yes, I had ... and? :-) Carl reserved 5 days for that. I am for implementation 
of all stuff from  the list. If you count the time needed, it is 
not more that 1-2 months to beta. After 3 years 1 or 2 months is 
OK with me ...

:)

I more care about the completness level, hence I am a bit surprised 
that e.g. CGI mode is not on the list and networking protocols are 
low priority. As for those, maybe Carl plans that community should 
do it. But as for CGI - why are not CGI related mezzanines in R3?

Because there has not been any discussion or proposals for what those 
mezzanines should be yet. There isn't even any CuureCode requests 
for such - only a request to get CGI working on Windows (it already 
does on Linux).

I have no idea what mezzanines you would want for CGI support. And 
can't really test them except in simulation, due to Windows CGI not 
working yet. What do you want?