AltME groups: search

Thanks for testing. I'd been wondering about that for some time

Based on some simple experiments I did some time ago, mezzanines 
are roughly 2.5 times slower than the aequivalent command (i.e. extension 
function).

And it was an objective, from way back when we did the first round 
of PARSE proposals. At the time I had been following the development 
of Perl 6, especially their rules enhancements. Some of the PARSE 
proposals were based on trying to catch up with or show up Perl 6, 
and others came from tricks that other parser generators like ANTLR 
could do (like IF). To be fair, it was an unstated objective, at 
least on the pages. Peta had different objectives of course, like 
better matching the PEG theoretical model, and those were also good.

This result looks quite unbelievable to me:

>> time-block [quote (x:)] 0,05
== 1.983642578125e-7

>> time-block [first [(x:)]] 0,05
== 2.46047973632813e-7

, how is that possible?

R2 would populate the block below with 200 (or so) random values.
R3 populates it with one value replicated 200 times.
Bug, nasty gotcha, or inexplicably elegant feature?

    random/seed now/time/precise
    blk: copy []
    loop 200 [append blk random/secure "abcdefghi"]
    print length? unique blk
    == 1    ;;R3's result (a110)

this is not worth discussing (I do not use JS at all, using only 
Java from time to time), but where did he use that in his code?

He is just imo trying to say, that rebol is incapable crap, as he 
does most of the time ...

That can be done in REBOL, but it requires planning for it ahead 
of time and a bit of explicit redirection. This is done in the R3 
GUI.

Although I use above from time to time, I don't like heavy class 
based code as I consider it very unreadable.. I've seen many such 
a (ActionScript) projects.

R3 Core is quite usable, but it still heavily depends on your needs 
(some areas are rougher than others). Basic graphics (draw) work 
on Win32 for hostkit builds. Performance on a script level was comparable 
to R2 (sometimes R3 a bit slower) for my uses, last time I did some 
measurements.

R3-optimized code is often faster than the equivalent R2-optimized 
code, and it looks nicer too most of the time, both due to native 
changes that make nicer-looking code more efficient.

BrianH, Ladislav, still have not understood why automatic delegation 
is so bad and not used in REBOL. From time to time this discussion 
arises again and again. Seems people are used to constructors and 
destructors and want them in rebol too.

Giuseppe, part of the reason that there are no set accessors (what 
I called "properties" above) in REBOL is that there are no classes 
either, so such accessors would need to be defined on a per-object 
basis. This makes them quite a lot less useful. The other part of 
your question is that we *do* have get accessors: We use the same 
syntax for variable getting as we do for function calls, so you can 
just assign a function to a word and it will act like a get accessor. 
You only need real get accessors in a language that puts parens around 
arguments or in some other way distinguishes function calls. However, 
let's for the moment assume that you mean get-word accessors, functions 
that will still be called even if you use the GET function, a get-word 
or get-path to access the value.


But one of the main reasons is to avoid hidden unexpected overhead 
and security issues. Assignment is fast in REBOL, because it does 
basically the same thing every time (with some variation in set-path 
assignment). If we had properties, that would add overhead to every 
single assignment statement whether to a property or not just because 
we would have to check for that every time. In languages with native 
properties their compiler makes this determination and generates 
the underlying function calls. With REBOL that overhead is at runtime 
because we don't have a compiler. We could compile our own dialects 
to make set-word accessors - Gregg's COLLECT, or R2/Forward's APPLY 
or MAP-EACH do this - but it is slower.


The security issue is that at the moment assignment and get-word 
access is safe. Set-path assignment and get-path access is at least 
safe with the built-in datatypes. Accessor assignment is not safe: 
it can have side effects or unexpected overhead. If we had accessors 
then you could not safely use words that you got from unknown locations. 
We wouldn't even be able to screen for functions, which a lot of 
the mezzanine code does now. Combined with get-word arguments and 
that means that there would be no way to avoid code injection exploits, 
and thus no way to make even a secure subset of REBOL. 


Now with path syntax the behavior is (apparently) type-specific, 
so with the appropriate datatypes we can do accessor functions; .NET 
object wrappers would benefit from this, for instance. But that requires 
utypes, because there is no point to making built-in types have that 
behavior. Then for security we could just disallow utypes from a 
function that might otherwise be exploitable.

An idea of NTP scheme, but servers comunicates only on 123 UDP port. 
overview of time services:

Daytime:  Ascii response,  Graham and Ladislav has written a scheme/tool 
already  port 13

Time: most simple possible server listening on port  37 answer 32bit 
unsigned number of second from 1-1-1900/0:00 (calculation of human 
readable date is not so trivial because of leaping seconds inserted 
to UTC with no rule at all, an Earth is dancing a Jive in fact)

HTTP: use inserted Date-time from any header returned from server 
port 80

SNTP: more precise protocol (contains also fraction of second in 
reply) subprotocol of NTP on UDP port 37

NTP: most precise available to compare more time servers, and calculate 
with computed transport delay and phase shift from evaluated couple 
of handshaking packets.  UDP port 37

The latter two use minimally 12  32bit binary packets for request 
and response, symmetric or asymetric cryptography possible (honestly 
I've no clue why this).

Ah, and at first I patched it away in Ruby in its build procedure. 
That was a long time ago

By that time, you'll still have to go through the same path of creating 
a COBOL interface

Yeah, that has been a difficult proposition for a very long time

POKE has to look up the function twice: Once from the word, the nect 
time in the action's datatype. Path evaluation at least knows what 
it's doing, so it doesn't have to figure it out.

the next time in the datatype's action list.

Does anyone have any information / Documentation on how to invoke 
a separate R2 program from R3 and/or vice versa?  In other words, 
is it possible to have an R3 script running and start up a separate 
instance of another R2 and/or R3 program to complete some tasks and 
then resume the original script?


Is it possible to time the event to run in a pre-determined amount 
of time?  Say like 5 seconds for the second program to run, if not, 
then show some error message.


What, if any, communications can occur between the programs, passing 
arguments, blocks, files, urls, etc.

A/1 is 2 time faster than FIRST A, on my config.

The primary reason for supporting NaNs would be for easy of interaction 
with systems that do support NaN, eg Oracle.


Right now, any REBOL system that was trying to trade values with 
an Oracle system that supported NaN and +/-INF would need to code 
for special cases.


However, I do not know of anyone who has such a need -- so time for 
some to make the busines case!

Here is an example showing a difference:


>> time-block [str: make string! 0 loop 10000 [append str "a"]] 0,05
== 0.0023125


>> time-block [str: make string! 0 loop 10000 [append str "a"]] 0,05
== 0.0024375

>> time-block [str: make string! 10000 loop 10000 [append str "a"]] 
0,05
== 0.002265625


>> time-block [str: make string! 10000 loop 10000 [append str "a"]] 
0,05
== 0.002265625

I don't have the time this week to do so, and am waiting on some 
more community understanding before I jump in. The "intrinsic property" 
thing likely won't survuve the cut, being replaced by the "implicit 
-of" thing.

yes.. it's the extensions posibility... I was doing some heavy math 
with images recently and I think it's time to move and start using 
R3.. at least for new scripts.. which also require to rewrite some 
old which I use often.

Give me some time and I'll get to that

he hasn't gone over the CC tickets in long time.

I apologize if I am not parsing your sentences correctly, ahead of 
time.


We use the term "value slot" because that is the official term, not 
because it fully describes the situation. It's just Carl's term for 
that 128-bit structure.
 

You seem to be misunderstanding what I meant by "immediate" values: 
I meant values of the dataypes in the immediate! typeset.
>> immediate!

== make typeset! [none! logic! integer! decimal! percent! money! 
char! pair! tuple! time! date! datatype! typeset! word! set-word! 
get-word! lit-word! refinement! issue! event!]

Any type not in this typeset is not an immediate type. I don't mean 
anything else by "immediate".


Nonetheless, if you like you can think of all value slots as being 
references, but these are not necessarily references in the C pointer 
sense. For many of the "immediate" types (as defined above) these 
are abstract references. For instance, consider [1]. The first element 
of [1] refers to the abstract idea of an integer, of the value 1, 
plus some extra stuff (like no new-line attribute). However, the 
block [1] just contains a "value slot" which has a bunch of bits 
in it. We have decided that those bits refer to the idea of that 
value (integer, 1, extra stuff), but finally they are just bits. 
If you change the bits, the new set of bits would refer to a different 
idea - the original idea is unchanged, just not referred to anymore 
by the block. This is close enough to "immutable" that we can treat 
"immediate" types as such, which is helpful for reasoning purposes.


Now here is the interesting part: We can consider *all* "immediate" 
types to be immutable. The word types contain pointers (effectively) 
to a symbol and a binding. However, the symbol is immutable, and 
the binding can be considered a reference value - what the binding 
refers to may be modified, but the reference itself is not (in the 
abstract). If you change either of those two pointers, this would 
make it a new word - the old symbol and binding referent are unchanged. 
The actual binding referent is considered to be a separate value 
from the word (a object or context). So, words are still close enough 
to "immutable" for reasoning purposes.


Where it gets iffy is when we get into types that are not in that 
immediate! typeset, because the "immutable" part is only references 
and offsets, not any part of the value that we would usually consider 
valuable. For the purposes of reasoning there really isn't much of 
the value that is worth considering to be inherently "immutable", 
and such types are worth flagging when considering sharing of data 
and other stuff. This is why these types aren't in the immediate! 
typeset (and why we have that typeset predefined).


The reason the typeset is called immediate! rather than immutable! 
is because the feature of the types that we want to emphasize is 
that values of those types, when passed to functions or otherwise 
assigned to other value slots, can at least in an abstract sense 
be considered to be copied to the other value slot (even if the abstract 
idea of the value is still abstractly referred to). This means in 
particular that changes to a value slot can't affect other value 
slots that refer to the same value (at least before the change). 
For non-immediate types all or part of the value is not copied on 
assignment, so changes to the original would affect at least part 
of the value referred to by the new slot. This is the crucial difference 
for CS reasoning purposes. We don't call them "immutable" directly 
because things like using path syntax to fake mutability of tuples, 
or PROTECT making stuff immutable, tends to confuse the issue.


Where it gets even more interesting is when you consider that the 
existence and implementation of value slots is actually irrelevant 
to the behavior of REBOL; all that really matters is the difference 
in apparent behavior between the immediate! types and the rest. You 
could have boxed unique integers and decimals that are referred to 
by pointers if you like, or symbols that don't exist except as unique 
numbers, or a generational or compacting collector that changes the 
location of the referents and updates the references accordingly. 
None of that matters as long as the system at least pretends that 
the immediate! types are unchangeable and copied on assignment.

{I apologize if I am not parsing your sentences correctly, ahead 
of time.} - I think, that you did well when parsing the sentences 
;-)


{We use the term "value slot" because that is the official term, 
not because it fully describes the situation.} - maybe I am the one 
to apologize here, I had no idea it was official, I thought, that 
it was not mentioned in the official documentation...


{You seem to be misunderstanding what I meant by "immediate" values: 
I meant values of the dataypes in the immediate! typeset.} - OK, 
so, I may need to be careful, and not mention any properties of the 
immediate! values, since they are not the reason why the immeditate! 
typeset was defined?

Cyphre, thanks for the FreeType code. It's a while ago that I looked 
at the src/os/ files, but they seemed fairly large and complicated. 
I won't have time to start that project until at least after ReBorCon

It's probably time to reactivate my Git hostkit mirror, and update 
it with those recent sources ...

Unlike JVM bytecodes, which were designed to be implemented in hardware, 
or CLR bytecodes, which were designed for JIT compilation, REBOL's 
semantic model was designed for efficient interpretation from the 
start, and then made more efficiently interpreted over time. A machine 
interpreter for the REBOL semantics would not really resemble the 
machine architectures with which you are familiar (maybe the Lisp 
machine?).

who cares the developpement is on hold Carl have better more profitable 
things to do than loose his time with rebol 3

But obviously, if no progress is made towards that anymore, it can 
still take a long time

R3 has a real chicken and egg problem. Much work could be done without 
Carl's direct involvement but for many people Carl's work is not 
yet sufficiently complete for them to do it. (A good example being 
the work you've put into R3 schemes, Graham).


The RM-Asset team are doing a great job of making progress with R3/GUI. 
Lets hope that they can continue and don't hit some issues which 
will need a lot of Carl's time to fix.

It is going to be a long. long time before there is a version of 
R3 published which inlcudes ftp, smtp and pop3.

I can't invest any time in R3 without a fully working GUI and https

Please note this in a ticket comment. It might be related to the 
sequence. In a fresh console on Windows, 6 will work every time.

6 works on Linux and OSX on a fresh console every time as well.

Well, he can only spend his time once

Dunno if anyone has the time for a demo contest http://synapse-ehr.com/forums/showthread.php?389-Demo-Competition

It usually is. It does seem disconcerting, but last time it lasted 
longer. The result was unicode support in R3. :-)

Not sure this one is controlled. This time we are nearing almost 
6-7 months of silence. Carl simply has a day job,not a supporting 
project imo.

I am still not happy with this:

    not none ; == true


, which means, that NOT handles NONE as a logic value. At the same 
time, it is not a logic value for other logic operators/functions:

    none or none

** Script error: or does not allow none! for its value2 argument


, and am tempted to put it to the CureCode. Am I the only one disliking 
this?

If our goal is not to break things, yes. If our goal is to clean 
things up for the long term, now is the time.

I find that R3 is the right time to address these issues in the language.


R3 is already incompatible.  I don't see a reason not to clean this 
up.

the whole bitwise thing is pretty fucked up anyway. i tried to do 
a disk editor, a pic microcontroller HEX file processor, a custom 
serial communication protocol and in all cases i had to ping-pong 
between binary! issue! integer! and had to trim to the right bit/byte 
counts. it was a nightmare all the time.

It's a long time since I studied set theory but if I remember correctly, 
the union of two sets is not dependant upon the order of the elements 
in a set.


So shouldn't the UNION of two sets of bits really be one of three 
values {0}. {1} or {0,1}.


I know this is knitpicking but I'm very used to XOR being bitwise.

FOUND? and TRUE? take time to execute, and often make it necessary 
to put code in parentheses, which also have overhead. Silly interpreted 
language stuff, but it's significant.

it raises the question, well what are these ops... and the answer 
is that there are none.   its a strange hole in the language spec 
which has passed under the radar for a really long time.

There are some real limits to op! evaluation that makes them unsafe 
for general use for now. For one thing, the type of the first argument 
is not checked at call time relative to the typespec by the evaluator 
- it has to be checked by the function itself internally. This is 
not a problem with most existing ops because they map to actions 
(which have their type compatibility handled by the action dispatcher), 
or in some cases natives that perform their own internal type checking. 
I believe this was a speeed tradeoff. If you allowed full user creation 
of ops even with their current restriction to actions and natives, 
you could bypass the typespecs of natives and corrupt R3's memory. 
Adding in that typespec check to the op! evaluator would slow down 
op! evaluation a little, but would be necessary if you really wanted 
to make user-defined ops possible.

It would be theoretically possible to make unary postfix ops in REBOL, 
as long as you used a different datatype or some flag in the op! 
value which could be set at op! creation time - the evaluation model 
of REBOL could allow such a thing. Ternary ops would be trickier: 
You would have to have the second word be a get-word parameter of 
the word! type be the underlying function's third parameter, and 
the third parameter of the op would be the fourth parameter of the 
function. All ternary ops starting with the same word would need 
to be implemented by the same function, which would behave accordingly 
based on which word is passed as its third parameter. The ternary 
op value itself would be assigned to the first word, because REBOL 
doesn't have multi-word bindings.

The only trick with ternary ops or infix keywords in REBOL would 
be that any syntax error that you might want to throw if the second 
word doesn't match the list of accepted keywords, you can't trigger 
that error until after the other parameters have finished evaluating. 
It would be preferable to trigger that error ahead of time, but impossible. 
Oh well.

Henrik, yes, I agree. I do that all the time.

That's what I do in most cases, but HH needs to be HHH (24-hour time). 
Sometimes I need to have sub-second or added extensions, but that's 
the basic idea.

I have my own date-time function, its pretty complete IMHO.

don't know if it works in R3 though....

	;------------------------------------------------------------
	;- DATE STUFF
	;------------------------------------------------------------
	; use this to prevent having to supply a spec all the time.
    ; the /default option of date-time sets this.
	default-date-time-spec: "YYYY/MM/DD-hh:mm:ss"
	                             
	
	;--------------------
	;-    date-time()
	;--------------------
	date-time: func [
		""
		/with spec ; specify

  /using thedate [string! date! time!] ; specify an explicit date instead 
  of now()
		/default
		/local str date-rules thetime
	][
		vin/tags ["date-time()"] [date-time]
		
		str: copy ""
		
		
		either spec [
			if default [
				default-date-time-spec: spec
			]
		][
			spec: default-date-time-spec
		]
		
		unless thedate [
			thedate: now/precise
		]
		
		
		if thedate/time [
			thetime: thedate/time
		]
		
		filler: complement charset "YMDHhmspP"
		;spec: "YYYY/MM/DD-H^^hmmP"
		;error: spec
		itime: true
		
		unless parse/case spec [
			some [
				here:
				(error: here)
				["YYYY" (append str thedate/year)] | 

    ["YY" (append str copy/part at to-string thedate/year 3 2)] | 
				["MM" (append str zfill thedate/month 2)] |
				["DD" (append str zfill thedate/day 2)] |
				["M" (append str thedate/month)] |
				["D" (append str thedate/day)] |

				["hh" (append str zfill thetime/hour 2)] |
				["mm" (append str zfill thetime/minute 2)] |
				["ss" (append str zfill to-integer thetime/second 2)] |

    ["rrrr" (append str fill/with/right/truncate (remainder thetime/second 
    1 4) "0" )] |
				
				["P" (append str "#@#@#@#")] | 
				["p" (append str "[--:--]@[--:--]")] | 
				["H" (
					itime: remainder thetime/hour 12
					if 0 = itime [ itime: 12]
					append str itime
					itime: either thetime/hour >= 12 ["PM"]["AM"]
					)
				] |
				["h" (append str thetime/hour)] |
				["m" (append str thetime/minute)] |
				["s" (append str to-integer thetime/second)] |
				["r" (append str remainder thetime/second 1)] |
				["^^" copy val skip (append str val)] |
				
				[copy val some filler (append str val)]
				
			]
			(replace str "#@#@#@#" any [to-string itime ""])
			(replace str "[--:--]@[--:--]" lowercase any [to-string itime ""])
		][
			print ["date-time() DATE FORMAT ERROR: " spec]
			print ["  starting at: "  error ]
			print ["  valid so far: " str ]
		]
		vout/tags [date-time]
		str
	]

Regading the word-activity of lit-words - it has been quite some 
time when I suggested to Carl to make lit-words "normal" in this 
respect, but he did not accept my proposal, so I expect he found 
it uncomfortable for some reason.

here is my ObjectID routine a'la mongodb.

wondering how much simpler could it be in r3?...  not that i could 
use r3 any time soon for production stuff, but i would love to, of 
course

  rejoin probe reduce [
    to-hex date-to-epoch now

    enbase/base copy/part checksum/method system/network/host 'md5 3 
    16
    skip to-hex access-os 'pid 4
    skip to-hex random/secure to-integer #ffffff 2
  ]

Now, for your questions, Kaj.


Mezzanines execute arbitrary code with DO. You can't even know if 
something is code or not until you pass it to a dialect interpreter 
like DO or PARSE - code is data. Blocks don't have bindings, only 
their any-word contents do, so the code blocks of functions are not 
bound to functions, only their contents are. The same goes for functions 
in modules or objects - they aren't bound to their objects or modules, 
only referenced by them.


(making this up on the fly) It could be possible to make the binding 
visibility of words be defined as a set of capability tokens as part 
of the object spec (in the SPEC-OF sense), and have the function 
spec dialect be extended to contain such tokens. This would have 
to be checked with every word access, and we would have to be careful 
to make the model in such a way to avoid unauthorized privilege escalation. 
Then changes in capabilities would happen on the function call stack, 
which is task-specific.


The problem with this is making sure code can't make functions with 
more capabilities than the code making them currently possesses. 
Though R3 doesn't really have a user model, it does have a task model 
and we could make the capability level task-specific. Code could 
constrain capabilities for code it calls, but we don't want privilege 
escalation at function creation time. It would be possible to have 
privilege escalation at function call time if the function called 
was created by something with the necessary capabilities.

Drawbacks:

- If we do this for binding visibility, this means a capabilities 
check would go into every word access. Word access would be SLOW.

- This doesn't add anything to the PROTECT/hide model, which handles 
binding visibility without the slowdown.


Capabilities would be like the SECURE model, but more flexible, so 
that's something to consider there. What SECURE protects is heavy 
enough that a capabilities check wouldn't add much to the overhead.

I don't see why capabilities would need to be checked on every word 
access. The critical point is the binding, and REBOL uses this well 
to optimise word access. Capabilities would need to be determined 
at binding time, so that binding will fail if the required capability 
token isn't available

Once the capability to reference an object or send a message has 
been granted, no further run-time check is required.

I hadn't checked E for a long time, but they are now implementing 
capabilities in JavaScript for Google, so we're going to hear from 
it whether we want or not:

IIRC, you provided some advice that helped with the R2/Forward version 
before it got included in R2 the first time. If so, thanks.

If allowing get-words in spec blocks, then QUOTE is fine. I'm questioning 
allowing get-words in spec blocks. It can lead to uses as this:


I make a function, that can do a paren! (in lack of better example, 
but it makes the point, I think):
>> do-paren: [:p] [do p]
I can try it on a paren:
>> do-paren (1 + 2)
== 3
Works ok so far, so I try having a var holding a paren:
>> q: quote (1 + 2)
== (1 + 2)
>> do-paren q
== 3
I got the feeling, I know how do-paren works, until I write:
>> do-paren quote (1 + 2)
** Script Error: do is missing its value argument
Hm, what if I use the old method:
>> do-paren first [(1 + 2)]

** Script Error: p expected series argument of type: series pair 
event money date object port time tuple any-function library struct 
even...

That's confusing, as I see it. (Example done in R2.)

It is great but a Waste of time. If only REBOL was open sorced DOC 
could put his offorts on it.

Also with all other languages, you have more than one implementation. 
I don't think, all those are waste of time. How many different C 
compilers have been made over the years?

By "valuable difference" I don't mean that one or the other behavior 
is preferable all of the time and so we should choose one, I mean 
that both patterns of behavior are valuable in different circumstances 
and so we need to support both. Both sets of functions are needed 
in mezzanine code, as they are now.

This is from R2:

>> next b
== [b c]
>> stats/series
== [34304 26141 7434 231 498 497 406]
>> next b      
== [b c]
>> stats/series
== [34304 26145 7444 231 484 483 409]
>> ++ b
== [a b c]
>> stats/series
== [34304 26151 7454 231 468 467 412]
>> ++ b        
== [b c]
>> stats/series
== [34304 26157 7464 231 452 451 415]


You see, NEXT increment BLOCKS (2nd number) by 4 each time. ++ increment 
it by 6 each time. So ++ take up more memory.

The area, head, tail and such attributes of a series are in the series 
itself, not in the reference to the series. This is good because 
series references are copied every time they are passed to a function 
- REBOL is strictly pass-by-value. All return values are copied too.

Yes, stats/series eat 3 blocks each time, it's called.

What if ... this is radical, but try go with me ... what if block's 
content wasn't bound to any context, when the block is made? And 
then the content is just bound to a context, when and if the block 
is being evaluated (or compiled if a language does that) the first 
time. Doing it this way, words are treated just like any other value 
within the block. They don't hold any other meaning than the words 
themselves. What would the consequences be?

I wouldn't have closure, but use object instead (or context, as I 
call them), if that functionality is wanted. And block content isn't 
bound to start with, so if I write:

>> f1: [a]
>> f2: func [blk /local a] [a: 2 do blk]
>> f2 f1
== 2


because 'a' inside f1 is bound to local 'a' in f2, when evaluated. 
If I want another 'a', I could write:


>> context [a: 1 set 'f1 compile [a]]	; f1 will be a block, [a], 
where the 'a' is bound to 'a' in the context
>> f2 f1
== 1

and the last result could be achieved:

>> f3: func [blk /local a] [a: 3 do compile blk]
>> f3 f1
== 3


Calling f3 will be slower, as blk is recompiled each time. This language, 
I illustrate, isn't REBOL, but another with many similarities to 
REBOL, but with a compile function. Maybe kinda the same could be 
achieved in REBOL, if the binding rules was changed, and "compile" 
in my examples above was changed to a "rebind" function.

Creating a new context every time the function is called is the whole 
point to closures, the only reason that you would use them instead 
of a function.

The PARSE statement in CLOSURE creates the code for a call to a function 
that the resulting outer function creates every time it is called. 
If you want to understand what the PARSE statement is doing, make 
a function with CLOSURE and look at its source.

Creating a new context every time the function is called is the whole 
point to closures

And R2 is not doing this with its functions?

Yeah, they will be reused. But the way, REBOL do it, if you have 
an application, that do a lot of block parsing for example, with 
new words coming in all the time, then that global context will just 
grow and grow. In reality, it will probably come to an end, as there 
are a finite number of words in a human language, if that's what 
being parsed.


If words were not bound by just being loaded, but only when evaluated 
(or compiled, if that's the case), then parsing blocks would not 
produce any unset! words in the global context. But a consequence 
of this is, that blocks of code being sent to a function (like LOOP), 
will be able to see the words local to that function, unless the 
block is first bound outside the function, like

	count: 1
	loop 10 bind [print count] 'count
, which will then print the number 1 10 times.

and it took 2h50m cpu time to get there :)

The time on mine won't be comparable because it's only running on 
one of 4 cores, and the others will be mildly occupied.

From 1.0G to 1.9G, after 14m cpu time

It failed a lot earlier for me (some time in the last half hour), 
never getting over 1.2GB, and now there isn't enough memory to figure 
out what the number it failed at was. Looks like you run out of memory 
before you run into the word limit, and that the symbol table isn't 
cleaned up by the recycler. Good to know.

John, you are missing some things others know and find obvious. For 
example, do you know the answer to the following question?

    What is the ratio between

        stringn: func [n] [head insert/dup copy "" #"a" n]


        word: to word! stringn 1 t1: time-block [equal? word word] 0,05

        word: to word! stringn 1000 t2: time-block [equal? word word] 0,05
        t2 / t1

compared to


        string: stringn 1 t1: time-block [equal? string string] 0,05

        string: stringn 1000 t2: time-block [equal? string string] 0,05
        t2 / t1
?

time-block? u mean delta-time?

(your naming is more intuitive though... it's also 'time in bash...)

I think, Carl will return soon and he will open source R3.

He must have a hard time doing that other job, but probably he will 
experience the bright side of the open collaboration too.

Im expecting him to realize that he can actually help the world effectively 
if he can unleash the power us, the long time fans of rebol.

time-block? u mean delta-time?
 I mean TIME-BLOCK:

http://www.fm.tul.cz/~ladislav/rebol/timblk.r

Geomol, refinements are not just for translating to paths. You can 
use a subset of the possible refinements for that purpose, but rest 
can be used for whatever reason you like in other dialects. REBOL 
is not just the DO dialect, remember. (This is the official answer; 
I am just writing it out again, for the 4th time this year.)

(This is the official answer; I am just writing it out again, for 
the 4th time this year.)

Why bother? No matter how many times you write it, this still is 
bad design. Or lack of design and bad implementation. It's like having 
integers, you can only use for the PICK function, but can't make 
arithmetic with.

It confused me, because they are called differently, so as a programmer, 
I think "ok, this is two different things, so I have to use time 
to learn the differences between e.g. functions and natives, or natives 
and actions, and how to use them correctly". And in fact, as a programmer 
I can very well ignore the differences, because the 3 types works 
exactly the same in my programs.

Ladislav, thanks for looking up the /local blog and getting the actual 
numbers - I didn't have the time. I think that the only votes against 
the change were by gurus, while the rest of the responding gurus 
abstained like me.

Geomol, about native-op!, native-closure! and native-action!, these 
won't be necessary. Functions of the native! type don't need to bind 
their bodies to contexts, so they don't need the feature that makes 
closures closures. Ops and actions both redirect to the actual implementing 
function, which in the case of actions is an internal native associated 
with the type of the first argument, and in the case of op is a (at 
the moment only native) function provided at op creation time. If 
you wanted to allow the creation of user-defined datatypes with function!, 
closure! or command! implementations of the type's actions, the regular 
action! functions would still redirect to these implementations. 
Similarly, the regular op! type could be extended to support redirecting 
to other function types without needing the creation of a new function 
type.

Functions of the native! type don't need to bind their bodies to 
contexts

 - in that sense, natives behave both as functions and as closures 
 at the same time. That is not as a big of an exception, as it may 
 look, e.g.:

    f: func [][]

behaves as a closure, similarly as

   g: func [x y][add :x :y]


, simply because in such simple cases it is not discernible whether 
the given "function" is a function or a closure

I was simplifying to avoid having to write a bunch of test code when 
my time is limited. Any proofs are welcome, though maybe the R2 proofs 
should go in Core.

The above list example proves, that lists don't "know" their index, 
and have to calculate it every time, which means, that "index access" 
is slow.

if it did not, it would have to calculate it every time

I'm not talking about calculating every time and changing of indexes 
being hold by variables and such. I only suggest, that INSERT does 
this:


If /only and if value being inserted is an index (or position or 
what we should call it) later in the same series, where we are inserting, 
add 1 to the index value and insert that.
In all other cases carrie on as usual.

So Robert, you also haven't been in contact with him? I thought he 
was working with you all this time. Hmmm.

This is by far the longest period of Carl's disappearance, IIRC. 
The reasons we can only speculate about - some personal/family difficulcies, 
burn-out to the REBOL topic, new daily job, which does not   left 
you with much energy and free time to do some other stuff, REBOL 
related.


We tried to get Carl's answer on R3 Chat, only with sporadic answer 
of recent Carl's job. But no answers to "what's next" for the REBOL. 
The reasons might be various again - Carl is willing to proceed, 
he just dosn't have time/energy. He is most probably not willing 
to open-source the project either, which gets us into kind of schizophrenic 
situation - no open-source, no progress either. If Carl would know 
the answer to what's next for REBOL question, he would already share 
it with us. But he did not do so, yet, which is a bit disappointing 
of course.


As for a phone call - I don't know - I would not call him, as it 
could get him into feeling, that we push him to give us an answer, 
which he might not have right now. But - I think that call from some 
friend, e.g. Reichart, would be accepted differently. But then - 
we can't push anyone to do anything, and from few weeks old discussion 
I think that Reichart does not necessarily feel urge to do such a 
thing, which is OK too.


So ... we wait ... and RED progresses at least, so hopefully in the 
end, there is still the chance that we will see the light in the 
end of the tunnel :-)

We are going to drive the priorities by the things RMA needs. This 
shouldn't be a problem for anyone because if you are going to use 
R3 for serious development than you will need it as well.


The thing is, that we are not going to jump-start for every requested 
feature etc. We know there is a lot to do and we will work through 
it step-by-step. And, this is not because we don't care what you 
all state here. Definetly not. I want to move R3 forward as fast 
as possible. This needs concentration, focus and pushing to finally 
get it done. At the end of the day the only thing that counts is, 
if we make it to make R3 stable enough for prime time development.