Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: Is Rebol code smaller?/Compiler!

From: carl:s:rebol at: 19-Nov-2002 15:48

Hi, this is Carl, and perhaps I can help clarify: The first statement is true. REBOL code is not known to be code until it is executed. Well written REBOL programs contain a nice mix of code and data that give the program greater power. GUI code is a good example of that. But, that trade-off makes REBOL tough to compile. The second statement is more complex, and Ammon is correct. If you code well, REBOL is quite fast for most tasks. In View, I've seen some GUI code scream, and I've seen the opposite too. Folks like Cyphre have written real time games, that amaze us... so the View compositing engine is quite fast (as fast as C code). The problem comes in knowing exactly what and how to control view faces (the "atoms" of GUI)... and for that, we need to provide you with more documentation... soon. Now regarding the theories... Yes, REBOL is strongly typed. Its datatypes are known immediately and are internally noncoercible (e.g. you cannot accidently use an integer as a string pointer). The language implementation takes great advantage of this (e.g. fast manipulation of things like X-Y pairs, images, tuples, etc.) Another way of saying this is: we don't keep datatypes internally in string format. Other interpreters (but not all) do. We don't. It's a speed advantage. Is REBOL more dynamic than Lisp/Scheme? In many ways it is. But, let's not start language wars here. (I've used Lisp/Scheme off/on for 20 years and have great respect for how it changed computing.) There are many differences. The languages are not father and son. Maybe more like brothers. The primary difference in dynamics has to do with evaluation (turning an expression into a result). In REBOL, the reduction is free ranging, that is, the syntax gives no clue to where the expression ends. It is determined by execution. In Lisp, it is bounded by parens, so you know where it ends. When REBOL begins an expression like: if find load %directory/ join %testing ".r" [print "it's here"] it has no idea at all what it will encounter as it proceeds. For example, starting at the beginning it does not know anything about the word IF. In most languages IF is a keyword, so it's a syntactic "anchor"... a fixed meaning. In REBOL IF may have been redefined, and it may have a different meaning in this context then it had somewhere else... in fact, it could even take a different number of arguments. And, don't forget that the expression above may be the result that was constructed dynamically from other REBOL code. So you see, when you look at REBOL from the surface, it's like looking at one side of a 3 dimensional object. That's only a projection in 2 dimensions. A simplification, if you know what I mean. But, that's good... because it makes REBOL simpler to learn and get started, but gives you some fun and power down the road, when you want to get fancy. And that can be very handy. Just some thoughts... I needed to take a break anyway. -Carl At 02:06 PM 11/19/02 -0700, you wrote:
>Hi, > > I will answer this much concerning REBOL and compiling; > > First, Carl said that REBOL code can be written so that it is too >dynamic to compile.(Or somthing to that effect) > > Second Carl also agrees that we need more performance out of REBOL. He >has talked several times about a function that they are working on that will >actually compile REBOL code. Now the examples he gave for a compiled >function would be heavy duty number crunching such as intensive algorithims >and bitmap processing. As far as the general 'run of the mill' code, I don't >think you will be able to compile it, and I think that the performance >increase would be minimal. The real trouble with performance is in things >like /View. > > All in all, I believe that RT is working on a solution to your current >problem. > >HTH >Ammon > >----- Original Message ----- >From: "Tim Johnson" <[tim--johnsons-web--com]> >To: <[rebol-list--rebol--com]> >Sent: Tuesday, November 19, 2002 10:50 AM >Subject: [REBOL] Re: Is Rebol code smaller?/Compiler! > > > <Tim> > There should be a rebol compiler or a system to translate rebol > > > > > > code into an Ansi C "dialect", which could then be compiled. > > > > <Ammon > This has come up several times and the reason there is no >compiler is > > > > > because of the dynamic nature of the language. RT is working on a > > > compile function, but it will only really work with heavy number >crunching. > > > > > Anything else done in the language is too dynamic to be compiled. >;-) > > > > <Tim> Is rebol more dynamic than 'scheme' or 'lisp'? > > > > (bigloo has a syntax for compile-time typing of 'words) > > > > > Tim, I would be glad to answer your question, but I have not used >any of > > > the languages that you mentioned (besides, of course, REBOL) so I am > > > entirely unqualified to answer. Sorry! > > > > Hi Ammon: (Rhetorical question, rhetorical answer) > > Disclaimer: I'm a bread-butter-programmer that just happens to use rebol > > and consider myself a mechanic among engineers and theoreticians when it > > comes to this list but to the best of my understanding I'll try the >following: > > > > REBOL is dynamic because it is interpreted. And according to [Carl--rebol], >rebol > > is influenced by LISP, and I can sure see that. Dynamic typing (a word >is > > typed when it is assigned a value) is a feature of interpreted >languages. > > > > It is arguable that Perl gains performance over rebol because the > > perl language syntax requires a certain amount of typing - > > defining a variable as *scalar* as opposed to *vector*. > > > > Some dynamic scripting languages like python are very up-front about the > > possibility that their scripted(interpreted) code might be slower than > > that of compiled application and suggest that prototyping might be the > > answer. > > > > On a more practical note, my company has been approached in the past > > regarding converting rebol code to "C" (which can then be compiled into > > free-standing executables that would (hopefully) offer superior >performance). > > > > The argument as to whether rebol is *more* dynamic that LISP or scheme >is > > probably moot. The convenience (and potentially smaller code set) of > > interpreted languages is certainly appealing to me. > > > > However when I and my fellow greying programmer colleagues drink too > > much latte and get into wild orgies of speculation, we come down to > > the agreement that the ideal programming language could be functional > > as interpreted *or* compiled. (bigloo is an example of such a language > > I think) > > > > I believe that there was a rebol compiler written at one time, or is > > that an "urban legend"? > > -- > > Tim Johnson <[tim--johnsons-web--com]> > > http://www.alaska-internet-solutions.com > > http://www.johnsons-web.com > > -- > > To unsubscribe from this list, please send an email to > > [rebol-request--rebol--com] with "unsubscribe" in the > > subject, without the quotes. > > > > > >-- >To unsubscribe from this list, please send an email to >[rebol-request--rebol--com] with "unsubscribe" in the >subject, without the quotes.
-Carl Carl Sassenrath Founder & Chairman REBOL Technologies www.rebol.com