World: r3wp

I was thinking named functions assigning results to their names, 
but with debug access that way will work too :)

I used a similar method to write the ONCE function.

Steeve, who are you?
Robert: http://www.colellachiara.com/devcon05/robert.html
Me: http://www.colellachiara.com/devcon05/john.html

Brian wrote "Your idea about a different word type for shared values 
won't work because words don't actually contain anything."


Don't say, it won't work. It can be made to work, if the will is 
there. I can think of many different possible implementations of 
REBOL with the current behaviour, we see. As I don't know, how exactly 
REBOL is implemented (I guess, only Carl does), I won't go in detail 
how to do, what I propose. Anyway, I personal feel, it might NOT 
be worth the efford to implement, what a programmer would observe 
as shared words. The C code will be more complex, and it will probably 
hit performance to some degree. Shared contexts within contexts as 
in R2 is probably just fine. Only problem (as I see it) in R2, is 
that it's difficult to not share contexts within contexts. But the 
R3 possibility to copy contexts can solve that. I think, the current 
R3 implementation of contexts (objects) and the copy semantics is 
far too complex.

Someone named Nick suggested having make/deep:
http://www.rebol.net/cgi-bin/r3blog.r?view=0239#comments

This could remove the need for copying contexts:

new-object: make/deep old-object [ ... ]

instead of what we have to do now:

new-object: make copy/types old-object any-type! [ ... ]

But the /deep refinement for make would only be used with objects, 
and it's maybe not ok to add a refinement to a function, if it's 
only to be used with one certain type of argument?

If not, then it could be solved with a new function: make-deep, make-new 
to something.

From time to time I ask myself, why I write so much about all this. 
It's because I care for the language, and I see many stange implementation 
decisions, and that's not good.

Geomol, my question was poorly worded.

I was wondering why Brian called you Robert (i didn't see the previous 
post from Robert)

Ah, ok! :-D

Oh my, it's not even enough to just copy/types, I have to do copy/deep/types 
to get a completely new object:

new-object: make copy/deep/types old-object any-type! [ ... ]

Does that look simple? No!

you just need to make a wrapper.

>>make-full: funco [obj spec][make copy/deep/types obj any-type! 
spec]

Is this such a pain in the ass ? ;-)

Yeah! I then need to remember to include this function in all my 
code. It would be better, if the language just did it right in the 
first place. ... time to make my own language. ;-)

Ask Brian for a mezzanine :-)

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 :-)