[EMAIL PROTECTED] wrote: > the stupid inliners in simple forthes doubled speed against the interpreters. > on older not so prefetchy superscalar processors. How could the compiler decide if a NATIVE! can be inlined? You can change the meaning of any word... > > Yes, but that's something different. You can compile if you pose > > limitations, making REBOL more similar to compiled (or compilable) > > languages. But then, what's the point in using REBOL? > > > > I'd prefer a solution like: > > > > my-native: make native! [ > > ; compilable REBOL dialect here > > ] > > > > that i mean with marking by hand. hotspot-compilers > do this marking at runtime, analysing if a word can I'd avoid such complexity. > > Why change the language, if you can just add a new dialect? > > because the language _is_ the dialect. it's not only > the syntax (blocks, 0x0) which one should recycle > in dialects, is as much as possible, like names ( > 'insert , 'if ), assignments ( a: ), argument-order > (desti first) ... result: if you make a dialect for a general-purpose-language, > it should look like REBOL. Probably, but it won't be REBOL; you couldn't treat code as data, for example. > second: a heavy problems with script-languages/ native > code is the interface. usually this needs lots of > conveter-code. i don't like [get-block-element-at > ref arg 1 42 ] if i can can do this stuff in a usual > function header.. /Command is able to call external libraries not designed to accept REBOL values, so I think there would be not so many problems in calling a function DESIGNED to accept REBOL values and written in a language that has primitives to handle those values. > oops, another last note: i have no real need for more > speed till now!! Wow! but i like compilers - techniques > :) :-) Regards, Gabriele. -- Gabriele Santilli <[EMAIL PROTECTED]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
