[REBOL] rebol weak points (i think) Re:(9)
From: g:santilli:tiscalinet:it at: 14-Sep-2000 17:12
> 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,
> 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
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/