AltME groups: search

The set-block! datatype would make good sense with functions, that 
return more than one value. In Lua, a function returning 3 values 
can be defined as:

function f () return 1, 2, 3 end

and be called like:

a, b, c = f ()


Now a, b and c holds the values 1, 2 and 3. In REBOL we have to write:

set [a b c] f

It would maybe be nice to be able to write:

[a b c]: f

I find it easier to write set [a b c] than to notice the colon on 
the end of [a b c]: - but that may be just me.

I'm working with a long time REBOL programmer these days. We discuss 
the language now and then. One thing, we discuss, is how the minimalistic 
syntax can make REBOL hard to read. We can use parenthesis for arguments 
to functions, but we rarely do it. We could write:

insert (back (tail (series))) value

but a REBOL programmer would just write:

insert back tail series value


Even if we use parenthesis, REBOL requre different parenthesis notation 
than other languages. The above code in C would look like:

insert (back (tail (series)), value);

kaj, no its its a system of associated nodes.

Maxim, I need that relevance think, was impressed by Ron presentation 
at DevCon France! My knowledge is less organized since I stopped 
using vanilla. I need to write a new wiki engine, have tried trees, 
nested set, adjacency, file system based, none satisfy me.

That means that you already had versions of those files in your work 
dir, and that get * didn't overwrite them. If you haven't made local 
changes to any files in that directory, do a purge-dir, then get 
*.

Is this a new error?

Nicolas, please check whether the return value from ON-CLICK can 
be a face. After clicking, it's possible to return a drag object 
and if a face object is returned, it might fail.

Just quickly reading about PHP's "return" function. It's interesting; 
it does not have to be in a function. It can return the evaluation 
of a script to the calling context.
http://us2.php.net/manual/en/function.return.php


Seems like a good idea to me. Maybe Rebol should incorporate this 
idea?

for a return code to the calling program

Not just for the os shell which has launched rebol, but rebol scripts 
that do other rebol scripts - the DO could be considered like a function 
call, and the DO'ed script could RETURN just as if it was a function.

The attractiveness of the idea is that there is just one function 
(return) to learn which handles the same concept (returning) in different 
contexts.

thanks Petr thats what I was looking for.  I'm in the process of 
putting together a small proposal for my company, and I hadn't seen 
much recently on the release scheduling on the R3 blog.

I would wait 6-12 months at least with using R3 in production apps, 
particularly if you are betting on advanced high level things like 
GUI. Development could start now, but R3 is not near feature freeze 
yet. Many moving targets and bugs remain. Cyphre is supposed to give 
the graphics engine another overhaul. We are also missing many docs 
for painless porting of R3 to other OS'es.


BTW: Carl has mentioned before that some things are needed for beta. 
I'm not sure the recent blog post is a good indication that R3 is 
anywhere near beta. I read it more like "this is a necessary 3.0 
feature".

If so, it could be, because he wants to remove the GUI from 3.0. 
I know he is going a bit back and forth on that.

It's just my speculation. The GUI can be removed if desired. It's 
going to be a module.

Henrik - a bit OT here, but maybe not. Have you looked into UIs of 
iPhone, HTC Sense (TouchFlo 3D)? I wonder if those glossy nice icons 
and other UI elements can be done using AGG and gradients, or are 
those things precisely rendered using 3D tools? Or are they just 
non-scallable bitmaps?

Well, to my mind, the GUI is written with Rebol code (it can be exported 
in a module). The graphic engine (GOBs, draw dialect) will stay in 
the core.
It depends of what you call the GUI.

releasing a REBOL beta without GUI is a VERY good idea.

with extensions all of the View internals can be outside... its basically 
AGG with a set of predefined hooks.  The only detail would be custom 
datatype... which should eventually reach extensions... maybe Carl 
could just build a special (undocumented) extension hook so that 
cyphre has access to more stuff, without the hassle of supporting 
it as a feature for the public.

on my part, once Carl adds either one or both of my requirements 
for the next evolution of extensions, then I can proceed with a fully 
independent version of a GUI written in OpenGL... no need for any 
internal view stuff a part from the image! datatype... not even window 
manager.

not sure it is good idea at all. But product packaging strategy was 
never explained for R3. Will there be Core, Command, View, Base like 
products? I am not sure, that technologically, R3 is done in such 
a way, so that such separation is possible (= all View internals 
can be placed outside R3 as a module). Also - having it optional 
as a module can lead to split of efforts once again.

So, I am still curious, how Core and Host parts are being abstracted/separated. 
And even then such separation does not mean, that View can be easily 
extracted outside as a module. Extracting only VID is imo nonsense.

to me REBOL the language and REBOL the platform are two different 
things.   forcing view as a requisite to rebol does not allow the 
language to live on its own.


if RT release the equivalent of core and makes that stable, we can 
already build a lot of apps, Back-ends, services, clients, etc.  
I'd rather have networking protocols, a stable set of mezz, continued 
improvements on extensions, than a lot of time waisted on view, delaying 
yet again all we can do with core already.

the OpenGL GUI will not need view, and if someone wants to make a 
cocoa extension or a windows native gui extension... they should 
not be forced to include view in their binaries.

a platform like view is a good thing, not saying it isn't, but its 
a different thing... to me, R3 is about the maturing of the language 
and of its interpreter.

Just noticed something else interesting about PHP. I just tried to 
generate an exception by division by zero. No exception was thrown! 
Instead, the result of the above expression was a boolean, false.

Re. new datatypes. Would all of set-paren!, get-paren! and lit-paren! 
make sense? Working like this:

>> a: 4
>> :(a)
== (4)		; type paren!
>> '(a)
== (a)		; type paren!
>> blk: [a b c]
>> (blk/2): 42
>> b
== 42

I suggested, a get-block! should work, so
:[a b c]
was the same as
reduce [a b c]
Maybe it's better, if it was:
reduce [:a :b :c]
?

I came to think of symmertry between parens and blocks. It make sense 
to me to have a lit-paren! datatype. What about a lit-block! datatype? 
The thing is, parens are evaluated by default, blocks are not. So 
a block acts like a lit-block! would, I guess. Is it a good idea, 
that blocks are not evaluated by default? A lot of functions take 
blocks as arguments. Some functions reduce their block argument, 
some don't. This can be confusing. If blocks were always evaluated, 
functions didn't have to reduce them. And then a lit-block! datatype 
would make sense.

Comments?

Example of functions, that treat they block argument differently:

>> first [a]
== a
>> print [a]
** Script Error: a has no value


If blocks were always evaluated, and we had lit-block!, it would 
look like this:

>> first [a]
** Script Error: a has no value
>> first '[a]
== a
>> print '[a]
a

Consequense is, functions had to be defined using lit-blocks... Nah, 
probably not a good idea. ;-)

The tuple! datatypes is in the scalar! typeset. Isn't it more like 
a series? Maybe it's because, a tuple can be max 10 bytes!?

John; I've become quite a fan of REBOL unreduced block data.  Super 
handy and learning the wisdom of it is a right of passage.

tuple! is a scalar  imho, well a scalar "record"    insert 1.2.3.4.5 
6  would do what?

But I still see a tuple! as a scalar type with no head or tail really.

I hope, we can one day make new datatypes. I would make a complex 
datatype. Wouldn't it be cool to be able to calculate:

1.2+4.5i * 3.14+1i

Or a range datatype:

>> blk: [a b c d e f g]
>> blk/3-5
== [c d e]

John, actually previous version of rebol had "aggressive" evaluations 
on some blocks in some circumstances and it was quite annoying in 
fact.  it got removed in 2.3 IIRC forcing us to reduce a little more, 
but now we have control.

if the rebol parser catalogued junk, it could shift to custom datatype 
hooks (just like parse tries to match patterns) until it finds a 
rule that says... "YES... up to here, I know what this means".

maybe with R4, after all of the goodies this opening will have brought, 
he will be able to contemplate opening up a bit more.  There is always 
a risk that letting go of *total* control can warp your creation 
to something you don't like.  But my experience in a decade of REBOL 
shows that stuff which isn't "sanctified" by RT have a lot of difficulty 
picking-up speed.


When you (i.e. Carl) spend 10 years on a project and it doesn't take 
off in-part because the responsability of keeping control stymies 
its growth, to a slower pace than that of the industry, IMHO you 
realize that the possible upside to *total* control definitely is 
dwarfed by having a mass of like-minded peers who move along with 
you.  


obviously no one sings exactly the same tune, but you need to try 
out stuff in order to know if its really a good or a bad idea... 
I'd rather have 100 people doing this, and then selecting the obvious 
clear winners than trying to muse about it, try a single idea and 
finally realize it wasn't a good idea.


Plus, what is good philosophy for RT isn't good for everyone... the 
proof is that the PITS model isn't enough for everyone.  Even RT 
had to acknoledge this.

REBOL "The language" is IMHO the best on the surface of Earth, but 
the platform (the actual executable, the desktop, view, IOS, et all) 
all show signs of tearing at the seams when you really want to "DO 
REAL WORK". 


You can get by, but its often painfull, or result to dubious work-arounds. 
  I have a lot of experience in big REBOL apps, so its not just word 
of mouth... I'm one of the few who has been succesffull at PITL work 
in R2 (hobby and commercial) for years.  But not everyone likes to 
say that problem-solving the platform itself is part of the work. 
 Most people want to work, they don't have time to try and fix view, 
or some tcp scheme, or charging their clients 30 hours to find a 
way to make 'CALL  work properly (or implement a MS COMLIB hack).

this looks like a vent, but its not.  I'm actually happy about everything 
that is happening with R3.   :-)

Every single broad decisision in R3 has been an enabling one for 
REBOL at large (both platform and language).   


Unfortunately, some things still require the core to be improved 
a bit, but we are nearing a point where REBOL will be able to fly 
on its own wings.   Just look at my attempt to get OpenGL to work 
with R3... it took me  10 hours of work from downloading the extension-enabled 
R3 version, downloading MS compiler, scrubbing the net for OpenGL 
reference material, libs, examples... and integrating all of this. 
 I've never coded OpenGL directly before... 


now imagine 100 of us doing this... that is what I see in REBOL's 
future within 2 years.  You will have things like trolltech QT bindings 
appearing, REBOL libs for any precise API out there... finally REBOL 
will be able to evolve with the rest of the world, and hopefully, 
impact its philosophy on the Computer Science more obviously...

JSON is a proof that it already has... now let's get that into the 
spotlight and start letting REBOL do what its really good at.... 
high-level application development...


 let it be the MCP for all the cool APIs, libs, network services, 
 game engines, web sites, smart appliances, etc... out there.


 (Refer to the movie Tron, for those who don't know what MCP stands 
 for... ;-)

JSON was inspired in part by REBOL's simplicity.  tis almost a 1:1 
match to rebol's data model... just with a different syntax.

if more people could actually USE REBOL daily, we'd see more of the 
philosophy of REBOL trickling into the industry.   People forget 
that REBOL is born out of a different perspective on computer science.

I don't see why you're having so much trouble... when I read the 
JSON reference docs a few months ago, I could almost do a replace/all 
of a JSON data set to REBOL's  seems pretty obvious to write a lib 
for.f

Ah, maybe you mean, my tuple t by itself doesn't have a position? 
So I can't do: next t

Maxim, the reason that custom datatypes can't extend the syntax is 
technical, not a control issue. When TRANSCODE/on-error was proposed, 
Carl revealed that TRANSCODE can't call out to external code on syntax 
exceptions without making it drastically slower, too slow for use. 
This is why the /error option was implemented instead: it doesn't 
use hooks or callbacks.


We do have custom datatype hooks for the serialized syntax constructors, 
but those are passed the preparsed REBOL data inside the #[ ]. Custom 
syntax hooks for ordinary literals would require a complete redesign 
of the parser, and that redesigned parser would be much worse, in 
terms of resource usage (speed, memory).

It was the compromise Carl came up with - my idea was the /on-error 
option, but that was rejected because it required TRANSCODE to call 
back into a provided function, something Carl said was infeasible.

Ah, Carl's back from few days off. Started to fight spammers on blogs 
a bit :-)

John, re set-paren!, etc. dataypes - I am not a fan of those

re "symmetry between parens and blocks": "it make sense to me to 
have a lit-paren! datatype" no need, use:

Is it a good idea, that blocks are not evaluated by default?

 - this is the way how dialects are supported; without it, you would 
 lose dialecting; EITHER, IF, LOOP, FUNC, etc. would have to be keywords, 
 not functions, ...

With QUOTE, Carl could also solve his block-path problem as:
(See http://www.rebol.net/r3blogs/0229.html)

>> user: [name: "Steve" age: 38]
>> user/(quote age:)
== 38

I prefer using a get-paren!:

user/:(age:)

On the other hand, I'm not a fan of letting user/age also search 
for set-words, lit-words and get-words.

Ladislav, I seem to remember, you once argued against get-words (or 
was it lit-words) as arguments to functions?

 - actually, that is a different matter. What I argued against was 
 "non-transparent" argument passing. The func [:argument] is not "just 
 a get-word", it is a specification of  "as-is argument passing". 
 As far as this one is concerned, it is much better than in R2; cf. 
 the QUOTE function, which cannot be implemented using any kind of 
 argument passing available in R2, while it is trivial in R3. The 
 "unevaluated words argument passing" specified by func ['some-word] 
 is still a different matter and I think that it is much less useful 
 than many users think. (e.g. the GET or SET function don't use it 
 for a good reason).

I wrote about it e.g. in http://www.fm.tul.cz/~ladislav/rebol/argpass.html
, but the article is a bit outdated

I only use lit-word parameters for console interactive functions 
(like CD) - otherwise it tends to be a bad idea. You can use get-word 
parameters for special tricks, but most of the standard special tricks 
have built-in functions in R3 implementing them already. It's usally 
easier to use one of the builtins (like QUOTE) than to navigate the 
tricks of reimplementing them.

There are a few years gone since I wrote my last c program under 
windows.
Just today I tried the extensions.
I was successful with Win-Lcc, but not with tcc.

Can someone tell me, if its possible to compile the extensions with 
tcc and how it should be done?

Thinking aloud for a bit in relation to the new Copy Semantics:
http://www.rebol.net/wiki/Copy_Semantics


What about the idea of protecting values. This way they won't be 
copied, when creatng a new object. Today we can protect words, but 
not values. So if a word is used for an indirect value, we can kinda 
change the word anyway (I say 'kinda', because we change the value, 
the word points to):

>> a: "a string"
>> b: a
>> protect 'a
>> change b "hmm"
>> a
== "hmmtring"


My idea is, that if we were able to protect values producing constants, 
this idea could be used to guide the creating of objects. And Copy 
Semantics could maybe be a lot simpler.

Would this seem like a REBOL way to create a constant?

define s "a string"

Used e.g. in an object this way:

o: context [
	define s "a string"
]


s can then be used as any other word, except it can't be modified 
(both the word and the value), and it won't  be cloned, when creating 
new objects from o.

To me, the best way is, if the rules are so simple, you're never 
in doubt when programming. I compare these rules to operator rules. 
In REBOL, operators are evaluated left to right. It's a lot easier 
to remember, than having to look at page 53 in "The C Programming 
Language" every now and then, when I program in C, because I can't 
remember all those rules.


I guess, it would be dead simple, if all values were cloned by default, 
when creating new objects. And then use constants for those, that 
you don't wanna have cloned.

I have never used PROTECT. Do you guys use that? Maybe a warning 
system would be better!? hm

Yes, I know. Is it too complex with copy/types? To me, it seems a 
bit complex.

From the docs:


COPY/types - specify as a typeset the values to be copied. Note that 
you can use /types without /deep, in which case the copy is applied 
only to the top level of values.


COPY/deep - perform the copy recursively on each value. If you use 
/deep without /types, it is assumed that you want to copy all series 
values (any-string!, binary!, and any-block!) but not bitsets, images, 
vectors, maps, functions, or objects.


I'm pretty sure, I won't be able to remember these rules, so I have 
to look it up, every time I use it. Result: I will probably not use 
it, if I don't really really have to.

Steeve, I sometime manage to accidently redefine words as TO. The 
result is, my script produce strange results, and it's a hard bug 
to find. I could consider protecting all the system words (there's 
a function to do that). But maybe better, if REBOL could give me 
a warning, when I redefine a system word (or maybe changing type 
of one of my own words).

If it's just for debuging purposes, it's a matter of habits.

Never used PROTECT to debug things because i have different habits

Do you accidently redefine words, you shouldn't have? Or do you have 
your own naming convention of words, so your own words will never 
be called the same as a system word? Or maybe you just are very good 
at remembering all the system words? :-)

First of all, i use local contexts everywhere, so that if i redefine 
a global words, the bad effect is limited.

Second: I mostly don't use mezzanines because i want my code as fast 
 as possible. So, I only have to remember the name of natives.

Third: I love REBOL and practices it every weeks, so it's not a pain 
to remember all the words.

fourthly: Because of that, i never do such bugs (except in old times)

This is a dirty hack of the LAYOUT function: you're warned if a set-word 
in the layout is not local.

use [x src][
	src: third find second :layout 'while
	src: first find src/forever block!

 insert back tail insert src [if same? in system/words x:][x [print 
 ["Warning:" x "is global var"]]]
]

Yup, I think, it might be a good idea to use that to guide copying 
of content within objects, so we don't have to have this complex 
copy semantics. A rule could be: protected values are like constants, 
and they don't get cloned, when creating new objects. All other values 
get cloned.
Makes sense to me.

A problem is though, if I wanna change such a protected value anyway. 
Then I have to first unprotect, change and (maybe) protect again. 
Alternatively, REBOL would need a new flag on values, that mark them 
as "changable constants" or "not-being-copied values" or whatever. 
A rule could be, that such values doesn't get cloned, but they can 
be changed effecting all objects having them.

>> ? in
USAGE:
        IN object word
        Returns the word or block in the object's context.
ARGUMENTS:
        object (any-object! block!)
        word (any-word! block! paren!) 


IN allow a list of objects OR a list of words as parameters but not 
together.

IN context [a: b: 1] [a b] == OK
IN reduce [context [a: 1] context [b: 2]] 'a == OK


But the more powerfull behaviour, to be hable to bind a block with 
a list of objects is forbidden.


IN reduce [context [a: 1] context [b: 2]] [a b] == ** Script error: 
invalid argument: [a b]

Why ????

There's a ticket about that already. "Why?" is that the behavior 
is undefined (as of yet).

It's hard to find a ticket about IN - the word is too common in English.

Can some of the R3 gurus answer a couple of questions I have regarding 
extensions (DLLs).


1. Is it possible to use a mutlti-threaded DLL? R2 can't receive 
return- data from a multi-threaded DLL.


2. Is it possible to do a callback into R3 so that I can use async 
calls to the DLL? Or do I still have to use a localhost interface 
for this?

I've thought a great deal more about shared content within objects. 
One problem is, they're called objects, because we then think of 
objects, as we understand them in other languages. If we think of 
them as contexts instead, then the goal to achieve is to share something 
between contexts.

Do we want to share words or values?


If we share values, then we could have one word in one context point 
to the same value as another words in another context. We can do 
this today with indirect values (like strings, blocks, contexts, 
etc.), but not immediate values like integers.


I think, it's better to share words between contexts. With this, 
I mean, that some word in one context should give the same value 
as the same word in another context, if I so choose.

>> same? context1/my-word context2/my-word
== true


And if I change the value for my-word in one context, then the value 
for the same word in the other context should change too (if I've 
specified this word to be a shared word). We can't do this with words 
representing immediate values in REBOL. So I see too simple solution 
(simple as in not complex):


1) Either a new type of word, the shared word, is implemented in 
the language, and this can handle both immediate and indirect values.

2) Or the simple R2 rule is enough. In R2, contexts within contexts 
are not cloned, but everything else is. We as programmers then have 
to put our shared words (representing all types of values, both immediate 
and indirect) inside contexts in our contexts (or using the REBOL 
terminology: inside objects within objects).

(Ah, good to get all this off my chest.) ;-)

... or we work with what we've got, which covers your requests, albeit 
a bit more complexly, otoh without the need to introduce new word-type 
:-) As for your second point, I want to have freedom to clone/share 
anywhere, not just whery system prescribes me to do so (subobject). 
You can post your comment to R3 Chat, to see what Carl thinks. Hopefully 
some other ppl will comment here ... especially Max ... where's MAX, 
when you need him? :-)

Geomol, regarding 1: Sounds good to me. And maybe we can make a big 
step forward to lazy evaluation including immediate values.

Robert:

1. The extension interface is currently single-threaded, but that 
shouldn't affect what the DLL does inside itself.

2. Devices are the standard R3 method of handling asynchronous behavior. 
Though the extension interface currently doesn't support the creation 
of devices, that is intended to be supported next. Maxim's callbacks 
may be supported too, but what you are talking about is a job for 
devices.

Geomol, the main problem with sharing is doing it in a manageable 
way. The advantage of using explicitly shared contexts is that you 
can know where your values are and distingish them from non-shared 
values.


Your idea about a different word type for shared values won't work 
because words don't actually contain anything. All values are stored 
in contexts, blocks or type-specific containers. All values "assigned 
to words" are contained in contexts, no exceptions. Even function 
words are associated with contexts. The question is which one.

R3 has two context types already:

- object!: Similar to system/words in R2, though for some internal 
instances (like error!) expansion is blocked. Direct reference.

- function!: Not expandable, stack-relative reference. Task and recursion 
safe.


Closures have object-style contexts, with a new instance created 
with every call (with bind/copy overhead on the code block, sort-of).

Robert, you can do lazy evaluation using functions that replace themselves 
with their results. Anything more requires a full language semantics 
overhaul, and might not be possible in an interpreted language. What 
do you hope to accomplish?

Right-click on their names. They've been here for a while :)

Sort of...


lazy: funco [code][does reduce [first back stack/block 2 to-paren 
code]]
c: context [
	a: lazy [b + c]
	b: lazy [c + 5]
	c: 2
]


>>probe c
==make object! [
    a: make function! [[][
        a: (b + c)
    ]]
    b: make function! [[][
        b: (c + 5)
    ]]
    c: 2
]

>> c/b
== 7
>>probe c
>>make object! [
    a: make function! [[][
        a: (b + c)
    ]]
    b: 7
    c: 2
]

>>c/a
==9
>> probe c
==make object! [
    a: 9
    b: 7
    c: 2
]

I used a similar method to write the ONCE function.

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.

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.

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 ? ;-)

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.

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.

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

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.