World: r3wp

D seems to have garbage collection. Then it isn't for this project, 
I'm doing. I can't have the computer having hiccups, because the 
garbage collector does some cleanup.

I'm ok with C for now. I was just pointing out, that REBOL dialects 
producing C source could be very useful for some kinds of programming 
problems. When I got the time ... ;-)

Geomol;  You can use std.gc.disable() for smooth runtime, and std.gc.enable() 
when 
and or if you want to turn the garbage collector back on.

See http://www.digitalmars.com/d/memory.html#realtime

They've thought about it! :-) Neat.

Yeah, my exposure to D is less than a month old, but I'm becoming 
quite a fan of
Walter.

How widely spread is it? Compiler for OS X, handhelds, alternative 
OSs? Does it speak with OpenGL and GLUT? What support of sound?

Umm, my exposure is still cursory.  But it's been working great under 
GNU/Linux.

Samples are sparse, but building.  iirc, the first release was January 
2007.
OS X support with through a gcc front/back end

Supports standard C lib conventions.  Links to all libs if I read 
that part correctly.  There

may be some import sequences to work out if it hasn't been done already.

Can someone explain why this function returns none?

foo: func[a[integer!]][switch[a][ 1["one"] 2["two"]]]  If you change 
it to switch[2] it will always return "two", so why doesn't the switch 
work when using a parameter?

switch value [ val1 [ ] val2 [ ] ]
and not switch [ value ]

anyone got any timestamp routines ?  digits only - no alpha - eg 
seconds since a partciular time?

ah... just use 'difference

you mean... difference now (wait 0:0:1 now) ?

just need to create sequential unique ids

btw... this is my favourite example of non compilable Rebol code: 
 b: [a b c] b/(print length? read http://rebol.comrandom 3)

b: ["yes" "no"] b/(exists? http://rebol.com)

but maybe it is compilationable

b: pick [[print "he"] [print "ho]] random 2
; ...
f: does b
; ...
f

now try to change the meaning of PRINT after the f: does b line, 
or maybe change DOES so that b is interpreted as a dialect...

see, for how smart the compiler would be, it would still be "interpreting" 
(or compiling and using the compilation result just once - which 
is the same) most of the times.

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.