World: r3wp

it's much easier to just have a compilable dialect that is used in 
tight loops and so on.

a simple not-compilable code example :  a/b

with 'a defined at runtime, could be object!, function!, string!, 
block!, etc...

Compilation doesn't necessarily mean ahead-of-time - it could be 
at runtime or function creation time. Type inference could handle 
a/b.

well, but the meaning (and so the datatype) of 'a and 'b can change 
during runtime, even a JIT can have a hard-time tracking those changes, 
don't you think so ?

it seems current JIT technology has become quite agile, as per Jaime's 
claim previously...

JIT inspects stuff prior to compilation, so I guess it will just 
remember to identify stuff and just make sure double infering is 
handled properly.

You are thinking that a/b means what a.b means in other languages 
- it doesn't. You can use type inference and partial evaluation to 
make it reduce to some simple behavior in many cases.

Most DO dialect behavior can be resolved at function creation time, 
so it's not even really runtime compilation.

how do you infer the type of 'a in such case :

c: call-function-returning-a-logic-value
a: make pick [object! block!] c [b: 1]
a/b ??

Rewrite the pick to an either and move the a/b into both code blocks.

Probably 90% of all rebol code is compilable. 

There may be some speed improvements if code was identified as such, 
eg....
        a: func/compilable [a b] [return add a b]

....could (in effect) inline the (current) assembler code for 'add 
and 'return....So if they change value, this code continues unchanged.

But what would we have saved? One level of lookup. Is it worth it?

I've been telling people, unless the compiler is really smart, don't 
expect too much of a speedup.

Brian, do you really think that one could write a usable compiler 
being able to handle such (too ?) specific cases ? How about that 
:

c: call-function-returning-a-logic-value
list: call-function-returning-a-list-of-datatype ; (1 <= n < ??)
a: make pick list c [b: 1]
a/b ??

do you think that a JIT could determine the type of 'list and 'c, 
and be able to take adequat decision regarding how he should handle 
'pick ?

Yes, but don't expect the output code to be much faster than standard 
REBOL code. If it can't infer the type it will have to output code 
that replicates the runtime behavior of REBOL.

BrianH;  I like to idea of using a REBOL to rebcode dialect.  JIT 
for developing.
Pre "compiled" for released scripts.

to = the / your

I guess that only a (small?) subset of REBOL semantic rules can be 
compiled to rebcode or native code. Maybe Brian has already defined 
that subset during his research.

(i mean, without resorting to some level of runtime evaluation)

rebol to rebocode compiler would be very usefull for math functions 
and image manipulations

rebcode math is faster than rebol, but C math is still lightyears 
awonder how big is smallest C compiler

for example I would like to see this equations as rebcodes http://www.robertpenner.com/easing/penner_easing_as2.zip

There is nothing really sacrosanct about the DO dialect's semantics. 
A compilable dialect could have different semantics that would be 
similar enough at the high level for most programmers to not have 
to change most of their code.

lightyears awonder = lightyears ahead. I wonder...

RT did something similar when they switched from R1 to R2. They switched 
from a Scheme-like engine to a Forth-like engine and most code was 
able to run without changes.

The question is, if such change can be done now? Or do you have just 
special subset of rebol language functionality having available to 
those who wish to compile?

Doc, my research has been put on hold waiting for R3. I can't justify 
using REBOL as a primary platform at work until I can make it integrate 
better with Microsoft technologies. Plus, they put rebcode on hold 
before they resolved the security/stability issues.


This research is going to have to be a spare-time thing for me for 
now, and I won't have any of that until after summer.

For one, i dont do stuff like in Gabrieles examples, dso if they 
perform terrible, i dont worry :)

For the ability, hotspot can do the following: it analyses the current 
code, sees, the is a virtuall call . but only one class with that 
method. and inlines the method. Later more code is loaded. now there 
are two classes, and the call must be really dispatched. Yes, it 
can change the code. I think that is somewhat similar to GAbirles 
changing of 'print.

For a/b, self did that long ago. it started with very flexible code, 
which checkt for object function and so on. keept track of what really 
occured. and generated optimized versions for the common cases. some 
runtime-checks for types, and branching to the quick version most 
of the time. quite fast results.

There's even solutions to combining type inference and partial evaluation 
that can make dynamic languages mostly static, and you can use type 
inference to make static languages that look like dynamic languages 
on the surface.

Brian, what kind of integration with MS technologies do you lack 
the most ?

Native library access to C is not enough, I need fast COM and .NET 
integration. Now that the DLR is out I may be able to implement the 
.NET stuff, when I get the time. With plugins and user-defined data 
types I could integrate COM. Mostly I would like to use /Services 
and I can't unless I can call them from .NET, or serve up .NET services 
to REBOL quickly. I think the lower overhead compared to SOAP would 
be a plus, but it has to be seamless, and as fast as local services 
when running on the same machine.

Cross-platform is not a problem for me - I can use Mono if I need 
to.

It would also be a plus to have proper WinCE support, as many of 
the people I support are running it in their cell phones. J2ME would 
be good for many others.

For instance, there are many REBOL desktop and network apps that 
would be much more useful with ActiveSync support (Qtask).

The ActiveSync APIs use COM.

Any proper WinCE app that stores data locally would need some kind 
of syncronization support too.

I would love to replace Outlook with Qtask, but can't without ActiveSync 
support.

The ActiveSync protocols have been reverse-engineered by the SynCE 
project team (http://www.synce.org/index.php/SynCE-Wiki). It should 
be possible to make an implementation in REBOL.

Reichart should pay someone to implement ActiveSync support.

Well, SynCE will help if I am connecting to WinCE from a non-Windows 
machine, but the ActiveSync program is already doing the connection 
on Windows, so I will have to integrate with that. Same on the WinCE 
side.

>> r: does [recycle set 'a "11111111" system/stats]
>> r
== 4460038
>> r: does [recycle set 'a 11111111 system/stats]
>> r
== 4460038

>> r: does [recycle set 'a ["1 1 1"] system/stats]
>>r
== 4460518
>> r: does [recycle set 'a [1 1 1] system/stats]
>> r
== 4460518

so.. is it fair to conclude that integers take up the same amout 
of memory as strings?

>> a: 1
== 1
>> to-binary a
== #{31}
>> a
== 1
>> a: "1"
== "1"
>> to-binary a
== #{31}
>> a
== "1"

It may be fairer and more accurate to say REBOL has some subtle optimizations 
in its memory allocation.

Watch, for example, the memory drop here.....you'll see that as the 
block 'x grows, REBOL allocates space in anticipation, so a single 
insert into 'x does not always change the stats.
x: copy []
st: system/stats
loop 500 [
    print [(st - system/stats) length? x]
    append x length? x
    recycle
   ]

>>r: does [recycle set 'a [#{7FFFFFFF}] system/stats]
>> r
== 4559204

>> r: does [recycle set 'a [6442450943] system/stats]
>> r
== 4562852

the first is the binary version of the second integer..  safe to 
say that a binary uses more mem than the integer?