AltME groups: search

With cloud tech so big now a cool product for rebol would be some 
kind of server/client DB with built in syncronization methods. I 
do not know if RebDB can be adapted to fit that bill...

You can repost in Announce group ...
 Need to finish documentation first.
Is it still pure ram based?
 ... Yes, but with two important differences:


 1) Values are stored in a binary! (reducing RAM overhead by about 
 50%)

 2) Reading/Writing a table to disk is easier/faster (as data is already 
 in binary! ... no conversion required)


Think of RebDB v3 as not so much a "database system", but a module 
that adds a new datatype ... table! ... which can be easily acted 
upon like any other REBOL datatype.

old version contained transaction log

 ... all the higher-level stuff is gone. It's purely a Storage Manager 
 now that enables you to create higher-level DBMS systems.
A testament to R3 code?

 ... Definately. The new 'apply and 'assert words among others make 
 things so much easier.
I do not know if RebDB can be adapted to fit that bill

 ... it can. RebDB provides the building blocks for higher-level abstractions 
 (much like ISAM files were/are the building blocks for DBMS's such 
 as DB2 and MySQL).
I hope I will be able to study a little what you did.

 ... I'd wait for the documentation ... the code is highly optimized 
 and rather terse. Without the conceptual model it's rather hard to 
 grok at first glance.

Yes. I deliberately designed it so that the index binary (which ideally 
should always be memory resident) is as small as possible and that 
the data binary only requires seek and append operations (which are 
well suited to disk access). I need to do a few more benchmarks, 
but the next release should include a "data on disk" option.

Maybe it's late and my eyes are not working properly.
I am starting to use REBOLDB for REBOL2.0.

I have read the quickstart guide and now I know how to create a table 
but.. wait: How do I open the table at the next start of my script 
?
I cannot find a DB-OPEN function.

if i do a commit *, then the replay.bak won't exist, but the server 
will still try to execute the session.log, which results in fractional 
changes:

Cheyenne is able to run RSP and CGI scripts concurrently on several 
processes at the same time. AFAIK, RebDB does not do any locking 
on write access, it would be unsafe to use in the general case with 
Cheyenne. SQLite would be more resilient, but keep in mind that as 
it is locking the whole DB on each write access, it is not scalable.

Here is related script which I use to crop images according it's 
alpha channel:
>> do http://box.lebeda.ws/~hmm/rebol/get-img-alpha-bounds.r

>> get-img-alpha-bounds load http://box.lebeda.ws/~hmm/rebol/alpha-image.png
== [53 6 99 121]

Maybe it would be better for someone more familiar with and interested 
in mathematical issues to do so. Ladislav?

as we tabulate votes we will post the confirmation codes here (in 
random order ;-) 


this will allow voters to confirm we've properly added their vote 
to our very sophisticaded vote counting system (a private group which 
will be made public the moment we announce the 2010 roty winner ). 
 


This is to make sure we do not miss your vote due to some possible 
altme bug. (like the first private post of anyone to me doesn't highlight 
their name in my PM list).  I will be logging off/on frequently in 
order for my PMs to be properly synced. 


NB: the voter names are not included in that group, in order to keep 
the votes anonymous.

Thanks for arranging this award for another year, Brian and Max.


I've voted for who I think will be a worthy winner -- and I hope 
everyone else takes the time to do so too.


For those who find AltME scrolling a pain, the voting protocol can 
be browsed here:
   http://www.rebol.org/aga-display-posts.r?post=r3wp558x302

graham, yes i would like to contribute to do a pestore like in R3

but i am not a guru in Rebol. and for me it is important to try to 
do this application to learn & to show the best practicies in R3, 
with the help of some guru ;-)

show why it is important to do something like this and not like that 
(performance, re-use of code,maintenance of code, etc...)

Using DOS (tested with VISTA and XP) I can launch my editor with:
>>start textpad

But how can I do that with the Rebol CALL function. It's doesn"t 
seems to work...

Jeez i wasted my time to develop a script to launch remote commands 
from an AS400 on my PC using FTP.

And I fail on the finish line because CALL don't do the last easy 
part of the job.
T_T

a little strange to use ftp to do that, but it's the only protocol 
allowed here :-)

Nothing to do but monitor the developers

What's the easiest way (under R3) to write code like this:

f: make function! [[][
	cols: [c1 c2]
	data: [2 4]
	cmd: [c1 + c2]
	set cols data
	do cmd
]


without adding words to the global context? (and not predefining 
c1, c2, etc).

Slightly clearer example of what I'm trying to do:

f: make function! [[cols data cmd][
	set cols data
	do cmd 
]]

f [c1 c2] [2 4] [c1 + c2]

Time to resume some R3 builds.  Do we have an ordered list of what 
we want to do next?

Just for those reading here (that is, please.... do not post web 
links to it), new wiki has:
www.rebol.com/priorities.html

Just for those reading here (that is, please.... do not post web 
links to it), new wiki has:

This group is web public !!

right now flushing out (finishing) the extensions is actually the 
most enabling.  so: 


1.  Releasing the view host-kit with improved extensions would be 
the first step into finishing WHAT the first R3 beta will be, in 
terms of architecture. Right now, there are a lot of datatypes missing, 
and a proper REBOL callback mechanism *** with return value***  is 
probably the most frustrating issue with R3 extensibility.  image 
and vector types are critical to extensions... please they have to 
be part of next extensions.


2. Schemes!!!   with a lot of work ALREADY done,  plus willing and 
able helpers, Carl, you should REALLY look into this and orient the 
spontaneous team that is dying to get your attention so they can 
proceed FOR YOU.


3. Documentation ... I'd say.. .TWO complete and final pages a day... 
no need to do more.   At that rate, the documentation will be much 
more helpfull within weeks.  But sections of it will start to be 
worthy of being called documentation... right now... I'd call it 
the "sprawled notes" part of the site.

SSL needs the ability to add devices, which in theory you can do 
in the host kit but noone has managed it yet. It would not be addable 
as an extension until we get device extensions. So many things are 
waiting on device extensions...

but don't see why this is bad, its very confined... I mean... its 
not like we're going to start seeing this in code:

do [cd]

just so we can supply less arguments and slow down our code.

Fixed tickets now at 14 and counting :-) A good sign R3 is back in 
development, although over time we do have few tens of tickets to 
implement :-)

What kinda value do you pass to to-utype?

strange ... I even tried to do those consecutive parse examples on 
the copy of data ... the result is still random ...

http://www.rebol.net/r3blogs/0307.html

A bit of work to do for those interested.

Thanks Sunanda. I've been holding off R3 as it takes "my all" just 
to write stuff in R2 and generally they are tools that "have to work." 
I feel badly though because so many of you are putting so much effort 
into it. I could definitely give a non-guru perspective. Thanks for 
all you guys do.

>> import %carte-joueur.r
>> import %carte-db-joueur.r
** Script error: joueur word is not bound to a context
** Where: make do applier make catch if import
** Near: make object! [
    table: 't_joueurs
    oo: make joueur []

Another method of importing modules is supported. If you use do on 
a module file, it will also be imported. This is provided as a convenience, 
because do has been used in REBOL for years as a way to load and 
initialize additional functions and values.

Claude, DO and IMPORT aren't the same thing at all. Scripts (loaded 
by DO) have a different context model than modules (loaded by IMPORT, 
DO or better yet the Needs header). Your scripts above don't set 
their type to module, don't export words, and have no name - they 
basically aren't modules. You should use DO and treat them as scripts 
until you better understand the module system. Ask in the "!REBOL3 
Modules" group here for more details and help, if you like.

How do we use them and how do we talk to them.

in other words head and next operate on file ports much differently 
then I would have expected.  I would have expected to have to do 
this:

port: head port

but this works:

head port

Next is the same way.

And if I want to use filenames as keys, I already need to do `to-binary 
to-string`

Portability has nothing to do with it :)

Probably to do with the new changes allowing us to protect object 
code.

Again, it may have to do with protection features.

Brian, if "Returns TRUE if the values are equal and of the same datatype 
& case." is OK, but "Returns TRUE if the values are equal and of 
the same datatype and case." is not, that's where I think uor priorities 
are out of order. 


Maybe the first thing we should do is write a clear goal for doc 
strings. What is their main purpose and what constraints should be 
placed on them for each purpose (or maybe I just haven't seen the 
doc that does this)? For example, are they be limited for console 
output only when listed with other funcs, or also when used with 
HELP individually? Should ? be short help and ??? link to a detailed 
help page for funcs? If console group list is the constraining factor, 
can it truncate and ellipsize longer strings?

Your unblock returns a series of words. You need to have them in 
a series (a block). You can do these:

first reduce [words-of my-object]
or simple
words-of my-object

I can't see, an unblock would be possible.

>> import %new_word.r
>> import %test_mod.r
** Script error: new_word word is not bound to a context
** Where: do applier make module do applier make catch if import
** Near: do body obj

AFAIK, import is for modules and your new_word appears to be an object 
This suggests that you should use do %new_word.r rather than import 
%new_word.r

But there is still lots of work to do for Core too. E.g. tasking, 
or other stuff listed in priority doc.

I've been misleading, what I wanted to say was: I do not get the 
error Petr describes, the demo comes up.

They probably had to break away and do some projects to pay some 
bills.

CONSTRUCT by default translates the built-in logic words to logic 
values, unset values to none, lit-words to words, and lit-paths to 
paths. This makes it easier to use it to handle headers. CONSTRUCT/only 
doesn't do any of those things - it only constructs the object with 
the data provided.

attempt needs to as lean as possible since it could be within loops 
being called a lot.  So I would propose that another solution might 
be to add another function.  Like to DEFUSE the block being passed 
to ATTEMPT.  So you can do something like ATTEMPT DEFUSE [some block] 
     The defuse function would return/pass the defused block to attempt 
to be evaluated.

Great analysis Brian. And I think Sunanda's point about arbitrary 
code is the key element for me. Some things we can address with language 
"Don do that", but error handling like this is very important to 
get right, and explain clearly (with examples of how to write robust 
apps).

How then can I get this code, executed from the command line, to 
always quit?
  r3-a97-3-1.exe --do "print true attempt [exit] print true quit"

From my perspective, attempt [break] is working correctly. ATTEMPT 
has nothing to do with the BREAK, it simply passes it to the outer 
context (if you can say that) and then the BREAK doesn't hold up, 
because it's not inside a function. Seems simple to me.

The question (only for Carl) is whether task-local runtime contextual 
information can be made available to BREAK, EXIT, RETURN and THROW 
to let them know that they are going to be handled by the console, 
which would let them throw the error that the console should be throwing, 
on behalf of the console. Basically, letting them be more polite. 
The problem is that it is *really* likely (only Carl would know) 
that this would slow down all function! and closure! calls, all loops, 
and every call to DO (even indirectly, as in IF) by quite a bit. 
It could make R3 a lot slower (maybe several times slower).

I see. That further proves how little ATTEMPT has to do with these 
errors. :-)

Sunanda, that error? try [....] code you keep mentioning doesn't 
work in all cases you mention. The problem is this:
>> error? break
== true

This is an error (bug#771 and bug#862): It should not return true, 
it should break and then later on trigger an error for an unhandled 
break. To illustrate why:
>> loop 1 [error? break 'buggy]
== buggy

That should have returned unset, not continued. The BREAK is supposed 
to halt execution and resume it somewhere else, either after the 
enclosing loop or at the top level. The same error is affecting your 
error? try [....] code, which is not behaving correctly. 


Your problem, Sunanda, is that you are thinking that ATTEMPT is not 
catching bad code (bugs) that it is supposed to catch - this is not 
strictly true. ATTEMPT isn't supposed to catch bugs, it is supposed 
to catch triggered errors. And a lot of logic bugs don't trigger 
errors, because the code itself is technically correct (what REBOL 
can check for), but not in accordance with the programmer's intentions 
(which REBOL can't know).


Now in this case the logic bug is that you have forgotten that the 
purpose of the BREAK, CONTINUE, THROW, EXIT and RETURN functions 
is escape from the normal flow of the code ("structured" gotos, aka 
non-local returns, exceptions, ...) - you remembered this about HALT 
and QUIT - and didn't realize that the error you are trying to catch 
with ATTEMPT is not in the code that you have wrapped in the ATTEMPT: 
It is not bad code. The error is triggered by the code on the other 
end, the handler, which is not wrapped in the ATTEMPT at all.

So you need to realize that this code is technically correct:
>> attempt [break]
** Throw error: no loop to break
but doesn't do what you thought it should.

And this code is absolutely incorrect:
>> error? try [break]
== true

but doesn't trigger an error because of a weird design quirk in R3 
that is arguably a bug, but not necessarily fixable (see bug#771 
and bug#862).

Do you need to access the elements as if they are in an object, or 
elements that are actually in an object?

Andreas, I don't have a problem with that solution in principle. 
It's just that it wouldn't work, and wouldn't be task-safe. The handlers 
for those functions would be task-local, the code blocks not. Plus 
it would break code that uses code block references rather than nested 
blocks, code that uses those functions through function values, and 
any function with the [throw] attribute (which we will be getting 
back in R3 with different syntax), and all of those exist in R3 mezzanine 
code. Plus there's all the extra BIND/copy overhead added to every 
call to loop functions, startup code, etc., and don't think that 
you won't notice that because that can double the memory usage and 
executiion time, at least.


The solution I proposed in the ticket comments is to have DO, CATCH 
and the loops set a task-local flag in the interpreter state when 
the relevant functions become valid, and unset it when they become 
invalid, then have the functions check the flag at runtime before 
they do their work (which they could because they're all native). 
This would be task-safe, only add a byte of task-local memory overhead, 
plus the execution overhead of setting and getting bits in that byte 
in a task-local way. It's the execution overhead that we don't know 
about, whether it would be too much. It would certainly be less than 
your proposal though.

It's funny: While regular R3 code looks a lot like regular R2 code, 
optimized code looks a lot different because the balance of what 
is fast and what isn't has shifted. At least regular R3 code looks 
a lot more like optimized R3 code than regular R2 code looks like 
optimized R2 code. This is because we have been focusing on making 
the common, naive code patterns more optimized in R3, so that people 
don't have to do as much hand-optimization. The goal is to make it 
so that only writers of mezzanine and library code need to hand-optimize, 
and regular app developers can just use the optimized code without 
worrying about such things.

btw, map-each is a burden, adding blocks by default.
Should be an option:  'map-each/only' to insert blocks,
Like other actions creating blocks do.

Andreas: what you ask for has been discussed extensively when R3 
was started, by me, Ladislav and Carl. There are a number of disadvantages 
to that, starting from the fact that you need to bind/copy a lot 
more than you do now (eg. inside CATCH). It would also, unfortunately, 
not work in cases like this:

I wrote the doc because we do need to solve this issue... probably 
in A99 or A100.

Or it should be an refinement to DO?

do/on-error


But then it's a question, if TRY should be there in the first place.

Just so that we can do some dynamic building of blocks with set-words 
and pass it to construct and not worry about a set-word getting assigned 
a value from the chain.

So often I think that mezzanines are not the answer sometimes to 
what could just be added as a refinement to an existing function. 
 Don't like to do that much to functions that are often invoked in 
looping or iteration routines.

The point isn't about whether or not I can do that.  I already do. 
 The point is that it offers more for the construct function to do 
at what I believe would be less cost with more to gain.

Paul, set-word!s are syntax for SET. [a: b: 2] is syntactical short-hand 
for [SET 'a SET 'b 2]. SET returns sets a word to a value and returns 
that value. If you don't want to pass the result of (SET 'b 2) as 
argument to SET 'a, then just don't do it.

Paul, you're basically asking for REBOL to do a fundamental change 
to its syntax inside construct.

So if I went to falcon or Lua and said do that and they did they 
could say they could handle such code safer than REBOL could.

let's say you have a service oreient protocal that is sending unencrypted 
blocks of data that is getting sent into contstruct on the other 
end.   All I have to do is capture it midstream alter the block and 
forward on and I can cause your code to behave differently.

I do Andreas, I have to currently use more bloat just like all of 
us do to handle it.

bloat is in the eye of the beholder.  To me where it takes more code 
to do something that could be done elsewhere is bloat in my book.

trying to do a bit of marketing/advocacy

(Continuing from "Rebol School".)


I've thought about TRY/EXCEPT too, since it popped up a few days 
ago. My thoughts are more about design. Why do we have TRY? Why not 
make /EXCEPT a refinement of DO? DO can do any type, TRY only works 
on blocks. If you wanna do a script on the net, and it can go wrong, 
we have to write:

try/except [do <url>] [<handle error>]

With /EXCEPT on DO, it could be:

do/except <url> [<handle error>]


My point is: is it good to have all these words in the language? 
It may add depth, but it also add confusion and complexity. Maybe 
the depth could still be there with fewer words, and the language 
would be easier?

I don't miss a simplification of DO/TRY as much as structures for 
sequential tests that may or may not fail. REBOL doesn't have anything 
here, so you have to roll your own. Say you're trying to connect 
somewhere in a protocol and one of 50 things can go wrong, so you 
have to state 50 tests, 50 error messages, 50 exit routes. That's 
a lot of lines of almost identical code.

There may be another concern with this. How do we get the error in 
the except block, so we can handle it? A common way is:

if error? result: try [1 / 0] [probe result]

This doesn't work:
(Remember to clear result, if you did the above first.)

result: try/except [1 / 0] [probe result]

And having /EXCEPT on DO is the same problem.

Henrik, yes, what you explain is a common problem. The best way to 
handle it, as I see it, is with a foreach loop, like this:

foreach [code handle-error] [
	[do something] [handle-error-1]
	[do something-else] [handle-error-2]
	...
] [
	if error? err: try code handle-error
]

Gabriele, yes, I didn't see that. So it should be possible to do, 
what I considered.

Raising again the now popular subject of error handling, I'd've thought 
this line of code should always print 'true....
    attempt [do "while [] []"] print 'true

....after all, it has no explicit 'RETURNs or 'BREAKs etc. It's just 
a bit  of unarguably bad code wrapped in an ATTEMPT.

(Not sure if this is a new test case, or (to Brian) an obvious application 
of the known issues; I think of it as a bug:)

Sunanda, we only have your word for it that do "while [] []" is bad 
code. You have done nothing to tell the interpreter that it is bad, 
and other programmers might be doing it on purpose. The interpreter 
can't tell the difference: It's all in your head. That's not an insult, 
it's an unresolvable communication problem between your intentions 
and the interpreter. The interpreter has to take you at your word, 
what you said to it is do "while [] []". Which it can, so it will.

Not just my word. Brian. If I type....
  do "while [] []"

..... in the console (R2 or R3), the _console_ tells me it is bad 
code.


Now, without wanting to reopen all the dicussion that has gone before, 
at the very least, this establishes that the console is not (in some 
cases) a good guide to how a line of code will be interpreted in 
a larger script.


Which goes against the traditional advice that the console is your 
friend -- such as offered here:
   http://www.rebol.org/ml-display-message.r?m=rmlMGGC

This would then leave us with the "classical" Common Lisp-style use 
of named catch/throw for non-local exits. And for this use-case, 
a definitionally scoped name would certainly be the right thing to 
do, imho.

Steeve, you might be amused to find out that the DO intrinsic currently 
depends on bug#1509 and does need a [throw] attribute. Though it 
still wouldn't work with definitional RETURN because of binding issues. 
C'est la vie.

I understand your take on Carl's proposal for a change in RETURN 
and EXIT scoping, but it needs some work before it can do the job. 
For one thing, if you have dynamic as an option (or a default) there 
is still the need for something like R2's [throw] attribute. And 
if definitional is an option, not the default, then I'm having a 
lot of trouble justifying that option, especially since it doesn't 
solve the [throw] issue or bug#1506. It seems to me that the main 
reason for definitional is to make a simpler default for less advanced 
developers. If it's an option that the user has to chose, it doesn't 
serve that purpose. And if it's an option that gets conflated with 
the option to specify a typespec for the return value of the function, 
then this is going to get Fork furious about making REBOL more confusing, 
and he'll be right this time.

It seems that functions don't bind 'self to the code block, but they 
do reserve it in the function spec. So that's a separate ticket.

No, it's solved. The bug was binding 'self in the code block, which 
it used to do and now doesn't (as of alpha 50).

Henrik, the /index option of EXTRACT assumes that there will be something 
there at the index (record length specified is assumed), and that 
the R3-style treatment of series bounds is in effect. That means 
that the programmer is expected to do their own bounds checking, 
or to not care. The none value is a placeholder for missing data.

Steeve, the second example you gave was missing a 2 on the end. But 
still, if that is the answer you want then that is a good way to 
do that. However, since EXTRACT is used for field extraction fron 
fixed-length records, Henrik's code is correct for that use. He just 
forgot to put a value in the proper place in the third record, so 
it returned none.

Correct is relative. EXTRACT/index is working as designed - it just 
wasn't doing what you wanted to do.

Internally, there is none. Ladislav is proposing that the internal 
'self field in the beginning of all contexts be made optional, with 
that option taken by MAKE object! (and as a side effect, modules), 
but not taken by contexts created by functions, closures and binding 
structural functions. As opposed to allowing the field to be overriden 
for that other stuff, and not doing the BIND trick with 'self in 
those cases (as we demonstrated we can do when that problem was fixed 
for closures).

Yeah, I think someone will have to do that :-)

Maui looks just New Zealand...except it is warm every day...  in 
fact I took almost no pictures when I went to NZ because it looked 
like my back yard.  


In the same day on Maui you can see snow, dessert, a dormant volcano, 
one of the most powerful computers in the world, swim with dolphins, 
tutrtles and whales, surf, shower in a waterfall, eat food all day 
picked directly off trees, and sleep under the stars...

The second day you can do even more :)

Reichart... do you need to *persuade* people to come to Maui? I assumed 
you had to keep them away...

Henrik, Good point.  

Will do when a prototype is doing at least "something" .


I will note, though, that if someone wishes to *officially* take 
up this task (especially testers which will have their hands at it), 
I will be more than happy.  My time is sparse, and documentation 
is time consuming.

we could then use tools like the !sea source parser and simply provide 
an easier way to declare the library functions (using the actual 
C source itself), as like I hope to be able to do.

I agree as well... mostly peope would like to use /library instead 
of extensions to do simple things like:
kernel32.dll: load/library %kernel32.dll
set 'MoveFile make routine! [
		"Moves file using OS"
    lpExistingFileName  [string!]
    lpNewFileName [string!]
] kernel32.dll "MoveFileA"

We don't want to download MS sources from MSDN to parse headers and 
integrate everything what's in kernel32.dll. Of course it may be 
cool in some cases, but we should keep it simple where possible.

for example actually being lua ruby or python most of their "regular" 
use  are to be merge as plugin into a host application that shares 
data with them Allowing to set up a base that will not change and 
an extention that will be faster to create ... This point is still 
in my opinion a strutural problem in rebol since in rebol data structure 
are hum ... special  and cool. 


One thing you can't do in rebol and that will miss us alot is for 
example the hability to create a ready made structure  in memory 
and map a file content directly to it. (For example in case of  "memory 
dumped files" in C ...) I could provide a detailled example but i 
think most of you saw what was my point...

@ all,   since there is no struct! or run-time generated datatype 
in R3 we basically have to start from scratch... we do now have a 
handle! datatype which is just like a pointer, which can be used 
as a reference to /library allocated RAM.


to help with visualizing my ideas here is an idea of how I see the 
/library import process happening:

maybe it will help relax apprehensions I have created earlier  ;-)



;-------------------------------
; importing libs
;-------------------------------

user32-lib: retrieve-library 'user32 [
	GetDesktopWindow:	:int32 ]
	OpenClipboard:		:int32 [Wnd: int32]
	close-clipboard:		:int32 "CloseClipboard"  ; note: renamed!  
]

my-lib: retrieve-library 'myown.dll [
	do-this:		:char* [my-arg: complex-struct* ] "DoThis"
	get-that:	:super-simple-struct* "GetThat"  
]



;------------------------------
; declaring structs:
;-------------------------------
super-simple-struct: [
	x: int32
	y: int32
]
complex-struct: [
	value: char*  ; a C string
	value2: int32
	int-array: int32 [50]
	buffer-ptr: byte* [4096]
	struct-vals: sub-struct [
		value3: int64
		value4: int32*
	]
	sub-struct: super-simple-struct
	struct-ptr: super-simple-struct*
	struct-array-ptr: super-simple-struct* [50]
]

;---------------------------------
; calling library stubs
;---------------------------------
window: user32-lib/GetDesktopWindow
user32-lib/OpenClipboard window
user32-lib/close-clipboard

;---
; with structures
;---

; on alloc, all members which aren't explicitely set are either set 
to  0, or  point to 0 filled arrays and structs.
my-lib/do-this alloc-struct complex-struct [
	value2: 2995	
]

coordinates: my-lib/get-coords


;-----------------------------------------------------------------------------

that's what I mean by simple  :-)


This is just a plan, an idea... its not a specification nor is it 
set in stone in any way.

thanks tom... that is a very nice real-world example I can work with. 
  

Do you understand the quick and dirty examples I gave above?  


 looking at it and without any other explanation, do you think you 
 would be able to map your example struct and would it solve all your 
 current requirements (assuming all the types are supported, of course)?


the one thing I DO NOT plan on supporting right now are unions... 
they just make a simple thing complex for no reasons... and they 
aren't that often used in the field anyways (for that very reason).

@ Robert, the reason for this /library (which is an extension) is 
that most REBOLers do not want to mangle with compiling C stuff (most 
probably don't even now where to begin).  and for most tasks, the 
speed hit isn't really noticeable.

Maxim asked me to take a look here...  it would be good to throw 
the main parts of this into www.rebol.net/wiki -- because it's hard 
to dive into the details in an evolving discussion, do you agree?

I was planning to use set-words to do those. For example:

sum: func [a [integer!] b [integer!] return: [integer!]]