Is Rebol code smaller?/Compiler!
[1/11] from: tim:johnsons-web at: 18-Nov-2002 10:21
* Ammon Johnson <[ammon--rcslv--com]> [021118 08:31]:
> HI, > <snip>
<<quoted lines omitted: 9>>> function, but it will only really work with heavy number crunching. > Anything else done in the language is too dynamic to be compiled. ;-)
My comment is rhetorical, I've no need for a rebol compiler, but your statement leads me to ask the following: Compilers are available for 'scheme' and 'Lisp', in fact the bigloo compiler for scheme produces benchmarks at the top of the language shootout. Is rebol more dynamic than 'scheme' or 'lisp'? (bigloo has a syntax for compile-time typing of 'words) -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com
[2/11] from: ammon::rcslv::com at: 18-Nov-2002 23:02
Hi, 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! Enjoy!! Ammon
[3/11] from: tim:johnsons-web at: 19-Nov-2002 8:50
<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
[4/11] from: gchiu:compkarori at: 20-Nov-2002 9:15
On Tue, 19 Nov 2002 08:50:21 -0900 Tim Johnson <[tim--johnsons-web--com]> wrote:
> I believe that there was a rebol compiler written at >one time, or is > that an "urban legend"? >--
Hi Tim, It was a long time ago in a place far away, but I dimly recall it was Joe Marshall who attempted this after leaving RT's employment. He tried to "compile" Rebol to Scheme. -- Graham Chiu
[5/11] from: ammon:rcslv at: 19-Nov-2002 14:06
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
[6/11] 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;
<<quoted lines omitted: 90>>>[rebol-request--rebol--com] with "unsubscribe" in the >subject, without the quotes.
-Carl Carl Sassenrath Founder & Chairman REBOL Technologies www.rebol.com
[7/11] from: tim:johnsons-web at: 19-Nov-2002 18:57
* Ammon Johnson <[ammon--rcslv--com]> [021119 13:29]:
> Hi, > I will answer this much concerning REBOL and compiling;
<<quoted lines omitted: 10>>> All in all, I believe that RT is working on a solution to your current > problem.
Hi Ammon: This isn't my *current problem*, and I'm just being rhetorical here.. but I would throw out an idea that make some sense and relevance to me: Imagine a rebol script that reads another rebol script and converts that script into "C" code that is compilable based on the following conditions: 1)The "C" code implies an API which could be provided as object code by RT itself, because I'm sure that they use something like it. 2)The code could then be either compiled directly or amended and then compiled. I could presume that RT already has those resources and could fit them to any of the OS's that the rebol binary is compiled to run on. Most Operating systems have a "C" compiler on board, I suppose that cygwin could be considered the default windooze compiler... 3)And it could be extendable by both extending the "preprocessor script" and the "C api". There just might be a market for something like that, and hey, there's a lot of "C" programmers out there.. RT's approach seems to be to create a "universe of their own". Perhaps it is worthwhile to think about how rebol can integrate into existing systems more? Just my two cents worth... in the meantime, I find that 75% of my programming needs are met with rebol. -tim-
> ----- Original Message ----- > From: "Tim Johnson" <[tim--johnsons-web--com]>
<<quoted lines omitted: 74>>> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com
[8/11] from: steven:white:ci:bloomington:mn:us at: 20-Nov-2002 7:39
>>> [carl--s--rebol--com] 11/19/02 05:48PM >>> >Hi, this is Carl, and perhaps I can help clarify: >And, don't forget that the expression above may be the result that was >constructed >dynamically from other REBOL code.
As a newcomer who struggles a bit with REBOL, I find these occasional essays very helpful. Perhaps they are candidates for saving in a library, or as a regular column on a web site. I personally print them and save them, so that I can reread them to help understanding gradually soak in to my age-encrusted brain. The idea of a language that can generate statements in itself and then execute them is interesting. That seems to be like this impossible COBOL example: 77 A PIC X. 77 B PIC X. 77 DATA-NAME-1 PIC X(50) VALUE "MOVE A TO B". PERFORM DATA-NAME-1. I might be beginning to understand what Edsger Dijkstra meant when he said that the use of COBOL cripples the mind. Steven White City of Bloomington 2215 W Old Shakopee Rd Bloomington MN 55431-3096 USA 952-563-4882 (voice) 952-563-4672 (fax) [swhite--ci--bloomington--mn--us]
[9/11] from: g:santilli:tiscalinet:it at: 20-Nov-2002 14:47
Hi Tim, On Tuesday, November 19, 2002, 6:50:21 PM, you wrote: TJ> Dynamic typing (a word is TJ> typed when it is assigned a value) is a feature of interpreted languages. Actually, word in REBOL are not typed at all. The just can reference any value. The value itself has a type. You cannot compile REBOL because you don't know anything at compile time. You don't know if a block is code or data; you don't know what a word is referencing unless you actually execute the code. I.e. if you'll really try to compile any REBOL script, you'll end up with embedding the interpreter in the resulting code, with maybe the chance of doing some minor optimizations in a couple special cases. I don't think it is really worth the effort. What would be useful to, instead, is offering something like: f: make native! [...] [ ; a compilable REBOL dialect here ] so that you can write in native code the performance-critical parts of your scripts. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[10/11] from: greggirwin:mindspring at: 20-Nov-2002 9:41
Hi Gabriele, GS> What would be useful to, instead, is offering something like: GS> f: make native! [...] [ GS> ; a compilable REBOL dialect here GS> ] I agree, but I think Carl once mentioned that another tricky issue is that certain OSs don't allow you to create code segments dynamically, so I'm not sure if that's even possible in all cases. Not sure how JITing works either, as might be applied to REBOL. -- Gregg
[11/11] from: nitsch-lists:netcologne at: 20-Nov-2002 21:39
On Wed, Nov 20, 2002 at 09:41:46AM -0700, Gregg Irwin wrote:
> Hi Gabriele, > GS> What would be useful to, instead, is offering something like:
<<quoted lines omitted: 5>>> so I'm not sure if that's even possible in all cases. Not sure how > JITing works either, as might be applied to REBOL.
AFAIK compiling and re-running a programm works everywhere. so a script could compile a specialized binary and launch it. with some version-checking to compile only the first time.
> -- Gregg
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted