rebol weak points (i think)

[1/48] from: rishi:picostar at: 9-Sep-2000 12:40

This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C01A5B.2D1D1280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've just started to play around with rebol. It definately has it's advantages for the beginner progammer but it seems shows some weakness for advanced, modular based programming. For example, all user/system defined variables are either global (or local to a function). Since all variables are global in rebol and there is no way to associate a variable with a class, this would probably lead to collisions when you are using lot's of scripts. imagine someone wrote a utility script with a bunch of reusable functions. Let's say you want to use those functions in your script. If the original script uses a global variable with the same name as a global var you used in your script, it would cause a collision. Or let's say that the programmer of a utility script reimplemented a rebol defined function such as "print." Now when you add his utility script to your script, the function print get's all screwed up in either your script or his script. Java and javascript have a much less chance of these collisions since the programmer can create static variable and functions that are associated with a class. These vars and functions can be accessed globally, but must have the name of the class in front of the variable. for example, Math.pi could be a variable pi defined in class Math that can be accessed globally.it is not an instance variable, it is a static variable. Outside of the class Math, you have to use "Math" before it in order to access it. Perhaps I haven't studied the language in enough detail yet, but wouldn't you all agree that this is a weakness in rebol? It doesn't seem that well suited for modular based programming as is. Maybe I'm missing something but I don't see why the author did it this way... Rishi ------=_NextPart_000_004B_01C01A5B.2D1D1280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META content="MSHTML 5.00.2614.3500" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV>I've just started to play around with rebol. It definately has it's = advantages for the beginner progammer but it seems shows some weakness = for advanced, modular based programming. For example, all user/system = defined variables are either global (or local to a function). Since all = variables are global in rebol and there is no way to associate a = variable with a class, this would probably lead to collisions when you = are using lot's of scripts.=20 imagine someone wrote a utility script with a bunch of reusable = functions. Let's say you want to use those functions in your script. If = the original script uses a global variable with the same name as a = global var you used in your script, it would cause a collision.=20 Or let's say that the programmer of a utility script reimplemented a = rebol defined function such as "print." Now when you add his utility = script to your script, the function print get's all screwed up in either = your script or his script.=20 Java and javascript have a much less chance of these collisions since = the programmer can create static variable and functions that are = associated with a class. These vars and functions can be accessed = globally, but must have the name of the class in front of the variable. = for example, Math.pi=20 could be a variable pi defined in class Math that can be accessed = globally.it is not an instance variable, it is a static variable. = Outside of the class Math, you have to use "Math" before it in order to = access it. Perhaps I haven't studied the language in enough detail yet, but = wouldn't you all agree that this is a weakness in rebol? It doesn't seem = that well suited for modular based programming as is. Maybe I'm missing = something but I don't see why the author did it this way... Rishi </DIV></BODY></HTML> ------=_NextPart_000_004B_01C01A5B.2D1D1280--

[2/48] from: ptretter:charter at: 9-Sep-2000 15:10

This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C01A70.269D0D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit You might want to look at the definitions for "bind" and "use". Also, look at the /local refinement by doing HELP FUNCTION. Paul Tretter -----Original Message----- From: [rishi--picostar--com] [mailto:[rishi--picostar--com]] Sent: Saturday, September 09, 2000 2:41 PM To: [list--rebol--com] Subject: [REBOL] rebol weak points (i think) I've just started to play around with rebol. It definately has it's advantages for the beginner progammer but it seems shows some weakness for advanced, modular based programming. For example, all user/system defined variables are either global (or local to a function). Since all variables are global in rebol and there is no way to associate a variable with a class, this would probably lead to collisions when you are using lot's of scripts. imagine someone wrote a utility script with a bunch of reusable functions. Let's say you want to use those functions in your script. If the original script uses a global variable with the same name as a global var you used in your script, it would cause a collision. Or let's say that the programmer of a utility script reimplemented a rebol defined function such as "print." Now when you add his utility script to your script, the function print get's all screwed up in either your script or his script. Java and javascript have a much less chance of these collisions since the programmer can create static variable and functions that are associated with a class. These vars and functions can be accessed globally, but must have the name of the class in front of the variable. for example, Math.pi could be a variable pi defined in class Math that can be accessed globally.it is not an instance variable, it is a static variable. Outside of the class Math, you have to use "Math" before it in order to access it. Perhaps I haven't studied the language in enough detail yet, but wouldn't you all agree that this is a weakness in rebol? It doesn't seem that well suited for modular based programming as is. Maybe I'm missing something but I don't see why the author did it this way... Rishi ------=_NextPart_000_0004_01C01A70.269D0D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 5.50.4207.2601" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV>You might want to look at the definitions for "bind" and "use".  Also, look at the /local refinement by doing HELP FUNCTION.  </DIV> <DIV> </DIV> <DIV>Paul Tretter</DIV> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left>-----Original Message----- From: [rishi--picostar--com] [mailto:[rishi--picostar--com]] Sent: Saturday, September 09, 2000 2:41 PM To: [list--rebol--com] Subject: [REBOL] rebol weak points (i think) </DIV> <DIV>I've just started to play around with rebol. It definately has it's = advantages for the beginner progammer but it seems shows some weakness = for advanced, modular based programming. For example, all user/system = defined variables are either global (or local to a function). Since all = variables are global in rebol and there is no way to associate a = variable with a class, this would probably lead to collisions when you = are using lot's of scripts.=20 imagine someone wrote a utility script with a bunch of reusable = functions. Let's say you want to use those functions in your script. If = the original script uses a global variable with the same name as a = global var you used in your script, it would cause a collision.=20 Or let's say that the programmer of a utility script reimplemented a = rebol defined function such as print. Now when you add his utility = script to your script, the function print get's all screwed up in either = your script or his script.=20 Java and javascript have a much less chance of these collisions since = the programmer can create static variable and functions that are = associated with a class. These vars and functions can be accessed = globally, but must have the name of the class in front of the variable. = for example, Math.pi=20 could be a variable pi defined in class Math that can be accessed = globally.it is not an instance variable, it is a static variable. = Outside of the class Math, you have to use Math before it in order to = access it. Perhaps I haven't studied the language in enough detail yet, but = wouldn't you all agree that this is a weakness in rebol? It doesn't seem = that well suited for modular based programming as is. Maybe I'm missing = something but I don't see why the author did it this way... Rishi </DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0004_01C01A70.269D0D60--

[3/48] from: al:bri:xtra at: 10-Sep-2000 13:03

Rishi wrote:

> Math.pi >> Math: make object! [

[ Pie: 20 [ ]

>> Math/Pie

== 20

>> Pie

** Script Error: Pie has no value. ** Where: Pie

Andrew Martin ICQ: 26227169 http://members.xoom.com/AndrewMartin/

[4/48] from: rishi:picostar at: 9-Sep-2000 19:12

no. The Math/Pie you have created is an instance variable not a static variable. It is associated with an instance of the class, not the class itself. A static variable means that there is a single copy of this variable associated with class itself. You do not need to instantiate a class to use static variable. For example: make-circle: make func [ radius /local blah-blah-blah /static num_circles ;let's say this is how you create static var. ] [ num_circles: num_circles + 1 ;this may not be correct but you get the idea... return make object! [ ;object code goes here ] ] small-circle: make-math(2) large-circle: make-math(100) print make-circle/num-circles ;this should hypothetically print out 2 print num-circles ;should print error Unfortunately, it would not make sense to add a static option the way I have done it since not all functions return objects. Anyway, the fact that rebol does not have static variables and static functions is no big deal. It was probably a concious decision not to include it. The main advantage of having static variables would be to prevent name collisions and to group variables/functions that act on a class (not an object) together for use in a more natural way. The main disadvantage of having static variables is that perhaps it is an unnecessary complication. But I don't think so. Maybe because I come from java/javascript background. I'm still wondering though if there is a way to have static variables that I don't know. Regardless, the main problem that I wonder about is if rebol is suited for modular programming where people reuse other people's functions/code. Since everything is either global or local, it seems as though it would be unnatural to use rebol in this way. Java has packages and stuff...perhaps I am not thinking straight and have too much java in my blood (which I have been doing to much of lately and finally got sick of all the abstractions that got in the way of doing simple stuff!!) Rishi

[5/48] from: al:bri:xtra at: 10-Sep-2000 14:57

Rebol Modules have been discussed by Carl Sassenrath. They should cover what you require, if an 'object! doesn't quite fit what you want. I'm getting a friend who has got a bigger collection of emails to post it to the list again or to find which message it was. Andrew Martin ICQ: 26227169 http://members.xoom.com/AndrewMartin/

[6/48] from: fsievert:uos at: 10-Sep-2000 9:16

On Sat, 9 Sep 2000 [rishi--picostar--com] wrote:

> make-circle: make func [ > radius

<<quoted lines omitted: 7>>

> ] > ]

You can use this: make-circle: func [radius /local num_circles] [ num_circles: [0] num_circles/1: num_circles/1 + 1 return make object! [ num: num_circles rad: radius ] ]

>> probe make-circle 99

make object! [ num: [1] rad: 99 ]

>> probe make-circle 88

make object! [ num: [2] rad: 88 ] or this: circle-maker: make object! [ num-circles: 0 set 'make-circle func [radius] [ num-circles: num-circles + 1 return make object! [ num: num-circles rad: radius ] ] ]

>> circle-maker/num-circles

== 0

>> probe make-circle 5

make object! [ num: 1 rad: 5 ]

>> probe make-circle 3

make object! [ num: 2 rad: 3 ]

>> circle-maker/num-circles

== 2 CU, Frank

[7/48] from: lmecir:geocities at: 10-Sep-2000 14:04

Hi Rishi, I think, that you are missing only complications here. What you are saying is, that Math below is an instance of Object! datatype. You are right. You are saying, that you would prefer it to be a class. But classes in a lot of languages (except for C++, Java, ..., AFAIK) are instances of object datatype too. There is only a little other language classes could do for you and Rebol objects can't, IMHO. (You can even create a Rebol class hierarchy using Rebol objects, as I demonstrated.) Regards Ladislav

[8/48] from: agem:crosswinds at: 10-Sep-2000 15:51

hi ho hi ho hi ho hi ... please note all.. as usual with functions, with objects to.. (i know you know, why else clone-object.. :) a: make object! [static: make object! [pie: 20]] and a/static/pie is static.. should one know again :) Volker [rebol [] ?do: func [todo] [prin ">> do " probe :todo prin "== " probe do todo] a: make object! [static: make object! [pie: 20]] b: make a [] c: make a [] ? a ? b print "------" ?do [b/static/pie: 10] ? a ? b ]

>>>>>

A is an object of value: make object! [ static: make object! [ pie: 20 ] ] B is an object of value: make object! [ static: make object! [ pie: 20 ] ] ------

>> do [b/static/pie: 10]

== 10 A is an object of value: make object! [ static: make object! [ pie: 10 ] ] B is an object of value: make object! [ static: make object! [ pie: 10 ] ] [rishi--picostar--com] wrote on 9-Sep-2000/19:12:06-7:00

[9/48] from: g:santilli:tiscalinet:it at: 10-Sep-2000 12:50

Hello [rishi--picostar--com]! On 09-Set-00, you wrote: r> I've just started to play around with rebol. It definately has r> it's = advantages for the beginner progammer but it seems r> shows some weakness = for advanced, modular based programming. r> For example, all user/system = defined variables are either r> global (or local to a function). Since all = variables are r> global in rebol and there is no way to associate a = variable r> with a class, this would probably lead to collisions when you r> = are using lot's of scripts. Actually, this is not true. You can create as many contexts as you like; think of a context as a "namespace", if you prefer. Also, you should also realize that REBOL has no variables at all, but only values. Furthermore, the new upcoming MODULE! datatype will make REBOL much more powerful that any other language with regards to modularity. r> Or let's say that the programmer of a utility script r> reimplemented a = rebol defined function such as "print." Now r> when you add his utility = script to your script, the function r> print get's all screwed up in either = your script or his r> script. Have a look at: my-object: make object! [ print: func ["my print" val] [ system/words/print val ; for example ] ] r> Java and javascript have a much less chance of these r> collisions since = the programmer can create static variable r> and functions that are = associated with a class. These vars r> and functions can be accessed = globally, but must have the r> name of the class in front of the variable. = for example, r> Math.pi math: make object! [ pi: 3.1415926535 ;... ] math/pi r> could be a variable pi defined in class Math that can be r> accessed = globally.it is not an instance variable, it is a r> static variable. = Outside of the class Math, you have to use r> "Math" before it in order to = access it. It can be made "static", too, if you need to. For example, with: math-statics: context [ ; the CONTEXT function is present in the ; latest experimental releases. values: [3.1425926535] ; etc. set 'math context [ pi: does [values/1] ] ] math1: make math [] math1/pi Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

[10/48] from: g:santilli:tiscalinet:it at: 10-Sep-2000 18:12

Hello [rishi--picostar--com]! On 10-Set-00, you wrote: r> make-circle: make func [ r> radius r> /local blah-blah-blah r> /static num_circles ;let's say this is how you create r> static var. ] [ r> num_circles: num_circles + 1 ;this may not be correct but r> you get the idea... r> return make object! [ r> ;object code goes here r> ] r> ]

>> make-circle: func [radius /local num-circles] [

[ num-circles: [0] [ num-circles/1: num-circles/1 + 1 [ ]

>> make-circle 10

== [1]

>> make-circle 10

== [2]

>> make-circle 10

== [3]

>> make-circle 10

== [4]

>> make-circle 5

== [5] Notice that:

>> source make-circle

make-circle: func [radius /local num-circles][ num-circles: [5] num-circles/1: num-circles/1 + 1 ] We achieved static "variables" with self-modifying code. More elegantly:

>> circle-context: make object! [

[ num-circles: 0 [ set 'make-circle func [radius] [num-circles: num-circles + 1] [ ]

>> make-circle 1

== 1

>> make-circle 1

== 2

>> make-circle 1

== 3

>> make-circle 1

== 4 r> small-circle: make-math(2) large-circle: make-math(100) print r> make-circle/num-circles ;this should hypothetically print out r> 2 print num-circles ;should print error Indeed,

>> print num-circles

** Script Error: num-circles has no value. ** Where: print num-circles r> Anyway, the fact that rebol does not have static variables and r> static functions is no big deal. It was probably a concious r> decision not to include it. The fact is, is has no VARIABLES at all. :-) r> The main advantage of having static variables would be to r> prevent name collisions and to group variables/functions that r> act on a class (not an object) together for use in a more r> natural way. OOP mainly means complexity, this is what we learned from history. If you change your point of view, you'll discover that you can do MORE in REBOL than in most OO languages. REBOL surely has weak points, but IMHO not being OO is its major strong point. And I was an OOP fan before learning REBOL. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

[11/48] from: rishi:picostar at: 10-Sep-2000 10:22

Thanks for all these responses. I think I will play around with rebol more so I can understand it better. This module! datatype sounds really interesting. I'd be interesting in reading the post Carl made on this that was supposidly posted some time back. I'd also be curious to know why rebol can't be compiled. Javascript, perl, python, java ... and most all languages i've seen can all be compiled (to at least byte code)... thanks Rishi O.

[12/48] from: carl:rebol at: 10-Sep-2000 18:34

So, why don't you guys just use the 'compile function? fast-sort: compile function [data [block!] return: [block!]] [a [integer!]] [...] print type? :fast-sort native! <grin> Turns out, you *can* write a compiler for REBOL. However, to do so you need to make "promises" about a function. You, the programmer, certify that the contents of the function is indeed compilable (by not using very late bound tricks). The benefit of the above is that you can use the rest of the REBOL environment for meta stuff... like preprocessing what you will compile. -Carl At 9/10/00 05:57 PM -0700, you wrote:

[13/48] from: larry:ecotope at: 10-Sep-2000 17:57

Hi Chris I agree. I don't see where Andrew's question presents any real problem. I suspect the primary problems with developing a compiler for REBOL are 1) The language design (or at least implementation) are not yet complete and 2) The semantics are somewhat irregular, so that there would be an awful lot of special cases to deal with. Scheme is another language which, in fact, is rather similar to REBOL in many ways (in REBOL 1.x, it was very similar, including continuations) and Scheme comes with a compiler as well as an interpreter (see the DrScheme package from Rice University http://www.cs.rice.edu/CS/PLT/packages/drscheme/. It is free and rather small (just a few MB) and supports threads, GUI programming, and tcp. -Larry

[14/48] from: chris:double:tab at: 11-Sep-2000 11:20

>Try compiling this: > > do ask "Please enter some Rebol code: "

FORTH and Lisp systems don't seem to have a problem with this. Most Common Lisp systems I know are compiled and have interactive input. See Corman Lisp for an example (http://www.corman.net). Generally the compiler is part of the run time and compiles the entered code on the fly. Chris. -- http://www.double.co.nz/cl http://www.double.co.nz/dylan

[15/48] from: al:bri:xtra at: 11-Sep-2000 10:54

> I'd also be curious to know why rebol can't be compiled.

Try compiling this: do ask "Please enter some Rebol code: " Andrew Martin ICQ: 26227169 http://members.xoom.com/AndrewMartin/

[16/48] from: larry:ecotope at: 10-Sep-2000 19:48

Hi Carl Hey, thats great... I always wondered how you guys incorporated new natives ;-) ROTFL But, seriously, I did not mean to imply that there *should* be a REBOL compiler. Personally, I much prefer to develop code using an interactive interpreter. I just wanted to make the point that one *could* make a REBOL compiler with a few restrictions on late binding, etc. (which would not effect most folks code). I am pleased that you agree. BTW I just wiped my local www.rebol.com directory and reloaded all the scripts using View 10.33.3.1. Everything ran OK except the boing.r demo which still redefines load-image and do-events. It's looking good. Could you say a few words more about index files (on the ALLY list or in publish). I see the new ones have the keyword 'always. Does that cause the local copy to be refreshed every time? Does summary work yet? Would you like us to put the byte size of files in the icon entries? Cheers -Larry ----- Original Message ----- From: <[carl--rebol--com]> To: <[list--rebol--com]> Sent: Sunday, September 10, 2000 6:34 PM Subject: [REBOL] rebol weak points (i think) Re:(6)

> So, why don't you guys just use the 'compile function? > > fast-sort: compile function [data [block!] return: [block!]] [a

[integer!]] [...]

> print type? :fast-sort > native! > > <grin> > > Turns out, you *can* write a compiler for REBOL. However, to do so you

need to make "promises" about a function. You, the programmer, certify that the contents of the function is indeed compilable (by not using very late bound tricks).

[17/48] from: civicminded4::yahoo at: 10-Sep-2000 20:48

--0-1714636915-968644136=:11554 Content-Type: text/plain; charset=us-ascii Whatever happened to the SHERMAN compiler, that I see, but cannot get, when I do a search of the web for REBOL? [carl--rebol--com] wrote: So, why don't you guys just use the 'compile function? fast-sort: compile function [data [block!] return: [block!]] [a [integer!]] [...] print type? :fast-sort native! Turns out, you *can* write a compiler for REBOL. However, to do so you need to make "promises" about a function. You, the programmer, certify that the contents of the function is indeed compilable (by not using very late bound tricks). The benefit of the above is that you can use the rest of the REBOL environment for meta stuff... like preprocessing what you will compile. -Carl At 9/10/00 05:57 PM -0700, you wrote:

>Hi Chris >I agree. I don't see where Andrew's question presents any real problem. I

<<quoted lines omitted: 32>>

>> >>

--0-1714636915-968644136=:11554 Content-Type: text/html; charset=us-ascii Whatever happened to the SHERMAN compiler, that I see, but cannot get, when I do a search of the web for REBOL?   [carl--rebol--com] wrote: <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">So, why don't you guys just use the 'compile function? fast-sort: compile function [data [block!] return: [block!]] [a [integer!]] [...] print type? :fast-sort native! <GRIN> Turns out, you *can* write a compiler for REBOL. However, to do so you need to make "promises" about a function. You, the programmer, certify that the contents of the function is indeed compilable (by not using very late bound tricks). The benefit of the above is that you can use the rest of the REBOL environment for meta stuff... like preprocessing what you will compile. -Carl At 9/10/00 05:57 PM -0700, you wrote: >Hi Chris > >I agree. I don't see where Andrew's question presents any real problem. I >suspect the primary problems with developing a compiler for REBOL are 1) The >language design (or at least implementation) are not yet co! mp! lete and 2) The >semantics are somewhat irregular, so that there would be an awful lot of >special cases to deal with. Scheme is another language which, in fact, is >rather similar to REBOL in many ways (in REBOL 1.x, it was very similar, >including continuations) and Scheme comes with a compiler as well as an >interpreter (see the DrScheme package from Rice University >http://www.cs.rice.edu/CS/PLT/packages/drscheme/. It is free and rather >small (just a few MB) and supports threads, GUI programming, and tcp. > >-Larry > >----- Original Message ----- >From: <[CHRIS--DOUBLE--TAB--CO--NZ]> >To: <[LIST--REBOL--COM]> >Sent: Sunday, September 10, 2000 4:20 PM >Subject: [REBOL] rebol weak points (i think) Re:(4) > > >> >> >Try compiling this: >> > >> > do ask "Please enter some Rebol code: " >> >> FORTH and Lisp systems don't s! ee! m to have a problem with this. Most Common >Lisp >> systems I know are compiled and have interactive input. See Corman Lisp >for an >> example (http://www.corman.net). Generally the compiler is part of the run >time >> and compiles the entered code on the fly. >> >> Chris. >> -- >> http://www.double.co.nz/cl >> http://www.double.co.nz/dylan >> >> </BLOCKQUOTE> --0-1714636915-968644136=:11554--

[18/48] from: joel:neely:fedex at: 10-Sep-2000 23:27

Hi, Rishi... Just a couple of points re REBOL objects that may be of some help: [rishi--picostar--com] wrote:

> no. The Math/Pie you have created is an instance variable not a > static variable. It is associated with an instance of the class, > not the class itself. A static variable means that there is a > single copy of this variable associated with class itself. You do > not need to instantiate a class to use static variable... >

1) The distinction to which you keep referring -- "class variable" vs. "instance variable" -- doesn't exist at all in REBOL because REBOL doesn't use the class-based object model of Java or Smalltalk. There are other ways to think of objects than simply as instances of classes . In NewtonScript and Self, for example, objects exist completely as standalone entities without any enveloping class. Instead, in both of those langauges, objects can have "prototypes", other objects to which they refer for common (or default) attributes and methods. In those languages, the object-to-prototype relationship is maintained throughout the lifetime of an object, so that changes to an attribute/method of an object are visible within any other objects that refer to the first object as their prototype (and that have not overridden the attribute/method involved). In REBOL, an object is a standalone entity. It may be created directly, using make object! ... or may be created using another object as a model or specification. However, it is cloned at the time of creation, and no longer maintains a relation to its model object. For example:

>> ob1: make object! [

[ attr: 23 [ meth: func [] [print attr: attr + 1] [ ]

>> kenobi: make ob1 [] >> ob1/meth

>> ob1/meth

>> kenobi/meth

>> ob1/attr: 2

== 2

>> ob1/meth

>> kenobi/meth

Notice that kenobi has its own copy of attr and meth which are independent of those in ob1 even though no explicit overriding was done at the creation of kenobi . Therefore all objects are created equal, without any "class" vs. "instance" distinction. Therefore the term "static" as used in Java or c++ is meaningless in REBOL.

> The main advantage of having static variables would be to prevent > name collisions and to group variables/functions that act on a

<<quoted lines omitted: 7>>

> functions/code. Since everything is either global or local, it seems > as though it would be unnatural to use rebol in this way...

2) I frequently use objects in my own REBOL programming to get exactly the benefit you're looking for: to partition the namespace. Most of my REBOL source files define objects to encapsulate all of the variables, subordinate functions, parse pattern blocks, etc. that make up the details of the main idea of the script. A limited number (often only one!) of the functions within the object are actually intended for use by the clients of the object. It's a handy way to structure and modularize libraries of code (and DOES offer a alternative to global and local). I write code in this fashion when I want to reuse it myself across many independent projects. Hope this helps! -jn-

[19/48] from: joel:neely:fedex at: 10-Sep-2000 23:38

Hmmm...

>> ? compile

No information on compile (word has no value)

So is the note below simply a gedankenexperiment, or is this in the works? -jn- "Anything can be compiled, but compiling arbitrarily ugly or complex code may not get you any benefits in time or space!" [carl--rebol--com] wrote:

[20/48] from: al:bri:xtra at: 11-Sep-2000 16:23

Larry wrote:

> I agree. I don't see where Andrew's question presents any real problem.

I agree too. If a compiler is included in the runtime. There's also a variety of SmallTalk which comes with it's compiler, and it would be nice for a larger version of Rebol to be like this. Andrew Martin ICQ: 26227169 http://members.xoom.com/AndrewMartin/

[21/48] from: rishi:picostar at: 10-Sep-2000 23:49

Thanks Joel! That was great help. I'm surprised I didn't think of using objects in that way. Rebol is more powerful everytime I look at it ...Simple but Powerful... And that modular architecture paper I just read (thanks Andrew...) sounds really interesting! I definately think I've found the language I've been searching for... Sorry about the html messages i've been sending to this list. My beos networking is down for some reason and I am stuck in complicated microsoft outlook program. Look forward to switching to qnx realtime platform soon!! By the way, did anyone write a rebapp to read/post messages on this newsgroups rather than having it come in my mail box? I am having to constantly subscribe/unsubscribe on demand depending on when I need to send messages. If their is such a rebapp, please let me know! (or do I have to write it?) And is there a way to read older archives of this newsgroup (like several months/years old) so I don't have to post questions that have been answered? Rishi

[22/48] from: al:bri:xtra at: 11-Sep-2000 19:34

Rishi wrote:

> By the way, did anyone write a rebapp to read/post messages on this

newsgroups rather than having it come in my mail box? I am having to constantly subscribe/unsubscribe on demand depending on when I need to send messages. If their is such a rebapp, please let me know! (or do I have to write it?) You could help us write it on: [RebMail--eGroups--com] Subscribe by sending email to: [Rebmail-subscribe--egroups--com]

> And is there a way to read older archives of this newsgroup (like several

months/years old) so I don't have to post questions that have been answered? There's an searchable archive of [list--rebol--com] at: http://www.rebol.org I hope that helps! Andrew Martin ICQ: 26227169 http://members.xoom.com/AndrewMartin/

[23/48] from: youpi:technologies:wanadoo at: 11-Sep-2000 11:26

Hello, Thanks for this discussion. I am interested by that since I had already posted a general question about OOP in Rebol. I have used a language which is Toolkbok who was created by Paul Allen and was the first Visual Language on Windows even before Visual Basic (Bill Gates even said to Paul Allen "Your product is marvellous. I'm going to copy it!"). Toolbook has very advanced OOP concepts and at the same time much simpler and more elegant than other languages. But the only thing that was really awful was that he coped with object directly without dynamic linking to some sort of prototype or class or whatever you want to call the ancestor. For building complex program with such a model is very easy but to maintain and reuse components in multiple projects all alive is very difficult without creating our own framework of MFC like in Visual C. I have exactly the same problem in Visual Basic which only knows Interfaces but completly ignore inheritance which is implemented in Visual C. So if you want to make some sort of industrial softwares (automate part of software conception) with the classic document-view architecture in VB and Rational Rose you will have tremendous difficulties. So I think I will encounter exactly the same problem in Rebol although I could make an architecture of messages sending that would implement some sort of inheritance as I did in VB. But as for now I didn't see enough advanced documentation in Rebol to be able to do it. The documentation is very well done but lack some advanced explanation about conception. So I look at some examples in rebol.org but still didn't see any example of architecture framework.

[24/48] from: bhandley:zip:au at: 11-Sep-2000 22:16

Hi, Rishi...

> By the way, did anyone write a rebapp to read/post messages on this

newsgroups rather than having it

> come in my mail box? I am having to constantly subscribe/unsubscribe on

demand depending on when I

> need to send messages.

You could also stick around and help others new to Rebol. ;-) Brett.

[25/48] from: joel:neely:fedex at: 11-Sep-2000 8:05

[youpi--technologies--wanadoo--fr] wrote:

> ... Toolbook has very advanced OOP concepts and at the same time > much simpler and more elegant than other languages. But the only

<<quoted lines omitted: 10>>

> document-view architecture in VB and Rational Rose you will have > tremendous difficulties.

You can use object composition, as in the following (hypothetical, built-by-hand) fragment of code. parent-object: make object! [ attrp1: 23 methp1: func [n [integer!]] [attrp1: attrp1 + n] methp2: func [] [print ["now up to" attrp1]] ] child-object-1a: make object! [ _parent: parent-object attrc1: 10 methc1: func [n [integer!]] [attrc1: attrc1 - n] methp1: func [args... [...whatever...]] [_parent/methp1 args...] methp2: func [args... [...whatever...]] [_parent/methp2 args...] ] child-object-1b: make object! [ _parent: parent-object attrc1: 10 methc1: func [n [integer!]] [attrc1: attrc1 - n] methp1: func [args... [...whatever...]] [_parent/methp1 args...] methp2: func [args... [...whatever...]] [_parent/methp2 args...] ] ;... as many as you want child-object-2a: make parent-object [ attrc1: 10 methc1: func [n [integer!]] [attrc1: attrc1 - n] ] child-object-2b: make parent-object [ attrc1: 10 methc1: func [n [integer!]] [attrc1: attrc1 - n] ] ;... as many as you want All of the "child-object-*" objects have the same interface, but the "child-object-1*" objects all delegate methp1 and methp2 to a common, shared, distinct object. In practice, parent-object is now fulfilling the dynamic role (NOT the initialization role) of a class in such languages as Java and Smalltalk. (The reason I emphasized "built-by-hand" is that you could write metaREBOL code to automate much of the construction, but diving into that level of detail right now would only obscure my point.) However, all of the "child-object-2*" objects all have no class ;-) since each is initialized with a COPY of the components of the spec object, but each goes its merry way immediatly thereafter. If you REALLY want to get obscure (and what good OO programmer doesn't ;-) the above technique obviously extends to simulate multiple inheritance. child-object-3: make object! [ _mama: parent-object-1 _papa: parent-object-2 meth-m1: func [args... [...whatever...]] [_mama/meth-m1 args...] meth-m2: func [args... [...whatever...]] [_mama/meth-m2 args...] meth-p1: func [args... [...whatever...]] [_mama/meth-p1 args...] meth-p2: func [args... [...whatever...]] [_mama/meth-p2 args...] ;... etc. ] I'll stop there, as I can't come up this early in the morning with good names for THREE parents... ;-)

> So I think I will encounter exactly the same problem in Rebol although > I could make an architecture of messages sending that would implement

<<quoted lines omitted: 3>>

> about conception. So I look at some examples in rebol.org but still > didn't see any example of architecture framework.

Someone once described FORTH as "not a programming language, but a programming language construction kit". I think that there's more than a grain of truth in applying that description to REBOL as well. It's just a matter of tradeoffs. Carl has given us a highly flexible, customizable, and extensible language. The cost of all those virtues is that if you really WANT to make REBOL code behave according to your mental model of language X (for all X ;-) you must do some of the plumbing yourself. That usually requires fairly sophisticated knowledge of BOTH languages. -jn-

[26/48] from: youpi:technologies:wanadoo at: 11-Sep-2000 15:21

Thanks I will look at that later on.

[27/48] from: allen:rebolforces at: 12-Sep-2000 0:19

> Someone once described FORTH as "not a programming language, but a > programming language construction kit". I think that there's more than

<<quoted lines omitted: 5>>

> (for all X ;-) you must do some of the plumbing yourself. That usually > requires fairly sophisticated knowledge of BOTH languages.

Well said Joel! REBOL as a tool of programing, much like paintbrush and paint are the tools of painting. Some of us will be modernists, some pre-raphaelite, some cubists and some will prefer water colours. REBOL (Unlike most art schools) will let us work in a style that suits us. Cheers, Allen K

[28/48] from: g:santilli:tiscalinet:it at: 11-Sep-2000 19:04

Hello [chris--double--tab--co--nz]! On 11-Set-00, you wrote: c>> Try compiling this: c>> c>> do ask "Please enter some Rebol code: " c> FORTH and Lisp systems don't seem to have a problem with this. c> Most Common Lisp systems I know are compiled and have c> interactive input. See Corman Lisp for an example c> (http://www.corman.net). Generally the compiler is part of the c> run time and compiles the entered code on the fly. So you want all of your script be compiled in a 400k executable? Anyway, that is not the problem. Let me know if you are able to compile the following code snippets: my-print: print-odd: func [a] [ print [a "is odd."] my-print: :print-even ] print-even: func [a] [ print [a "is even."] my-print: :print-odd ] repeat i 5 [my-print i] 1 is odd. 2 is even. 3 is odd. 4 is even. 5 is odd. --- ; this is just an example... amiga: make object! [ send-to-par: func [something] [write/binary %/par something] play-sound: func [sample-data] [write/binary %/audio sample-data] ] unix: make object! [ send-to-par: func [something] [write/binary %/dev/lp0 something] play-sound: func [sample-data] [write/binary %/dev/dsp sample-data] ] others: make object! [ send-to-par: func [val] [] play-sound: func [val] [] ] code: [ send-to-par some-data-for-the-printer play-sound hello-sample play-sound goodbye-sample ] current-system: get pick [ ; going by memory, the actual table might be different... amiga others others unix ; etc. ] system/version/4 bind code in current-system 'self do code --- ; self modifying code code: [ ; initialization, needs to be run the first time only random/seed now remove/part code 5 print random 10 ] print mold code loop 5 code print mold code

>> print mold code

[ random/seed now remove/part code 5 print random 10 ]

>> loop 5 code

5 6 6 3 7

>> print mold code

[ print random 10 ] Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

[29/48] from: agem:crosswinds at: 11-Sep-2000 22:17

[g--santilli--tiscalinet--it] wrote on 11-Sep-2000/19:04:09+2:00

> Hello [chris--double--tab--co--nz]! > On 11-Set-00, you wrote:

<<quoted lines omitted: 7>>

> c> run time and compiles the entered code on the fly. > So you want all of your script be compiled in a 400k executable?

Compiling the compiler into the runtime? Compilers can be small..

> Anyway, that is not the problem. Let me know if you are able to > compile the following code snippets:

<<quoted lines omitted: 12>>

> 4 is even. > 5 is odd.

Wheres the problem? yes, by default you have to lookup each call in a table. for speed, to inline the primitives, there is a need for hotspot-style compilers. or marking never-changing code by hand ("compile func"). (like a stronger [protect 'if] which can't be removed (in the module)). problems arise if you do a: func[a b][] ; 2 args user: func[][ a 1 2 ] a: func[a][] ; 1 arg user do you?

> --- > ; this is just an example...

<<quoted lines omitted: 25>>

> bind code in current-system 'self > do code

if bind is allways bind/copy this works. note we have early binding in rebol, which gives very good hints what will be called (can be reduced to indirect addresses IMO). Compiler has to insert calls beetween the addresses, yes.

> --- > > ; self modifying code

i know SM-code is possible, but is it usefull? maybe usefull if rebol could access its callers pc. do you know of some use? which can not be reduced to some parts, allowing for something like "compile func" for others? if you know, can we apply a forthish way? : make a block-entry big enough for some usefull code, like add, if, .. and of course indirect call . if you bind to a froozen primitive, copy its code, else insert a call. if you store to a speed-block! , its more costly, and you have to fight with code/data-cache-sync. with fixed block-size one has to insert some nops too. but modern prefetchers may like this way more than interpreter-jumps?

> code: [ > ; initialization, needs to be run the first time only

<<quoted lines omitted: 21>>

> print random 10 > ]

i think this would be hard: caller: func[][my-dialect these are dialect-words!] my-dialect: func[][ parse-caller[dialect stuff] ] but it does not exists.. and finding the 'b in a/b very quick, as long as there is no type-system with fixed offsets. But, there is rebol/command with some typing stuff. Carl in front of his C compiler: Can't be long until he thinks that job can be done by Rebol too. if he changes the language a bit.. If he localizes the restrictions.. Components, Modules, we can't change them too.. Speed by simplification - he has done it before..

> Regards, > Gabriele. > -- > Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer > Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/ >

Volker

[30/48] from: chris:double:tab at: 12-Sep-2000 9:28

>So you want all of your script be compiled in a 400k executable?

No, I was just making the point that it seemed to be possible to compile REBOL, not that it was a necessity. As an aside, Corman Common Lisp for Win32, the console application (equivalent to Rebol/Core I guess) is a 600K executable. But then it doesn't include the source as part of the executable, or the networking, etc, etc.

>Anyway, that is not the problem. Let me know if you are able to >compile the following code snippets:

Are you asking if it is possible to compile the code snippet you give in any language or in Rebol? If any language, the following works fine in a compiled Lisp and I can't imagine why the same wouldn't work in a compiled REBOL either: (defun print-odd (a) (format t "~A is odd.~%" a) (setf (symbol-function 'my-print) #'print-even)) (defun print-even (a) (format t "~A is even.~%" a) (setf (symbol-function 'my-print) #'print-odd)) (setf (symbol-function 'my-print) #'print-odd) (loop for i from 1 to 5 do (my-print i)) Gives: 1 is odd. 2 is even. 3 is odd. 4 is even. 5 is odd. Your other example, the amiga, unix, etc objects and binding the methods to the code is quite neat. This could be compiled where 'do' is the equivalent to other languages 'eval'. In a compiled language with 'eval', the 'eval' can either interpret the results or wrap the eval into an anonymous function, compile that function and then execute it. So the following would be the equivalent to implementing an eval: (eval '(do-something)) => becomes (funcall (compile (lambda () (do-something)))) The result of that compilation is executed. Obviously speed of compilation becomes an issue. Self modifying code as in your next example becomes a tad more difficult to compile :-). I wouldn't know how to do it myself without changing the code to use some sort of 'eval' type of thing. Personally REBOL is fast enough to do the sorts of things I use it for anyway so I don't have a problem with it being compiled or not compiled. It amazes me that something like REBOL/View can fit into such a small package! Cheers, Chris. -- http://www.double.co.nz/cl http://www.double.co.nz/dylan

[31/48] from: brian:hawley:bigfoot at: 9-Sep-2000 10:05

[rishi--picostar--com] wrote:

>no. The Math/Pie you have created is an instance variable not a static >variable. It is associated with an instance of the class, not the class >itself. A static variable means that there is a single copy of this variable >associated with class itself. You do not need to instantiate a class to use >static variable.

You have it backwards. REBOL doesn't have classes. OOP in REBOL is prototype/delegation based, like Self, NewtonScript or JavaScript - not class-based like C++, Smalltalk or Java. Objects in REBOL are all unique. Their behavior is defined within themselves using static variables, rather than through their class. They are created from prototypes, not classes. Constructors are just functions. You don't inherit the features of a class, you call them directly - this is known as delegation. All fields are static - any instance objects you create call the "class" objects directly. This style of object-oriented programming, used properly, can be more efficient than class-based programming. If you really need classes they're a simple design pattern away.

>For example: >make-circle: make func [

<<quoted lines omitted: 8>>

> ] >]

There are techniques for making persistent values in functions - most of them are arcane (but fun). Functions don't have static variables as such but you can embed structured data in the code of the function. Most of the time it's better to use objects. Try this: circle-class: make object! [ num-circles: 0 new: func [value [number!]] [ num-circles: num-circles + 1 make object! compose [ class: (self) radius: value num-circles: func [] [class/num-circles] ] ] ] (skipped a little...)

>The main disadvantage of having static variables is that perhaps it is an >unnecessary complication. But I don't think so. Maybe because I come from >java/javascript background. I'm still wondering though if there is a way to >have static variables that I don't know.

It's interesting that you mention Java and JavaScript in the same sentence here. Java is class-based like C++. JavaScript is more like REBOL - all variables are static, constructor functions, class factory objects instead of classes. The object model of JavaScript has been traditionally confusing for those who think OOP is only class-based...

>Regardless, the main problem that I wonder about is if rebol is suited for >modular programming where people reuse other people's functions/code. Since >everything is either global or local, it seems as though it would be >unnatural to use rebol in this way. Java has packages and stuff...

Coming from a background of Oberon, Delphi and such (among many others) I'd have to agree. Fortunately RT has listened :) Look at this: http://www.rebol.com/reps/rep002.html It's a little outdated - many changes have purportedly been made already but they haven't been codified yet. I gather security support will be much improved. Still, it's a taste of things to come. I'm looking forward to it :)

>Perhaps I am not thinking straight and have too much java in my >blood (which I have been doing to much of lately and finally got >sick of all the abstractions that got in the way of doing simple >stuff!!)

Tell me about it :( I'm having the opposite problem. I just got put on a project that is being done with ColdFusion, a web template language like ASP. I can't go 5 minutes without running into some limitation that would be trivial to overcome with REBOL. Maybe I can do the next round with REBOL/Serve when it comes out... Brian

[32/48] from: g:santilli:tiscalinet:it at: 13-Sep-2000 11:36

[agem--crosswinds--net] wrote:

> Compiling the compiler into the runtime? Compilers can be small..

Even if it has to be smart enough to compile REBOL?

> Wheres the problem? yes, by default you have to lookup > each call in a table. for speed, to inline the primitives,

Would that really be faster than the current interpreter? Just a bit, I think. Is that worth the effort?

> there is a need for hotspot-style compilers. or marking > never-changing code by hand ("compile func"). (like

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 ] where you can speed up critical code. That would make REBOL the most powerful language --- you have speed, and you have a powerful high level language.

> if bind is allways bind/copy this works. note we have early binding in rebol, > which gives very good hints what will be called (can be reduced to indirect addresses IMO). > Compiler has to insert calls beetween the addresses, yes.

But then again you need the compiler in the runtime; I have dubts that such a "REBOL compiler" could be dramatically faster than the current interpreter. If you, instead, express the speed critical parts with an ad hoc designed compilable dialect, and then compile those, you get a dramatic speed improvement with just a little effort.

> i know SM-code is possible, but is it usefull?

It can be. You have the power, but have to use it with wisdom.

> make a block-entry big enough for some usefull code, > like add, if, .. and of course indirect call . if

<<quoted lines omitted: 4>>

> too. but modern prefetchers may like this way more > than interpreter-jumps?

I still think that's not worth the effort, but I might be wrong. The "COMPILE ..." or "MAKE NATIVE! ..." solution seems to me much simpler and useful.

> Can't be long until he thinks that job can be done > by Rebol too. if he changes the language a bit.. If

Why change the language, if you can just add a new dialect? If RT just includes some kind of fast "byte code" interpreter or compiler, then the compiler from the dialect to teh byte code can be easyly done in REBOL. It's much simpler, isn't it? Just IMHO, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

[33/48] from: petr:krenzelok:trz:cz at: 13-Sep-2000 11:58

[g--santilli--tiscalinet--it] wrote:

> [agem--crosswinds--net] wrote: > > > Compiling the compiler into the runtime? Compilers can be small.. > > Even if it has to be smart enough to compile REBOL?

IF Rebol would be properly modularized, e.g. much earlier discussion about one and only /Core.exe, others as loadable components, or just ability to 'package appropriate components into one .exe, even compiler could be separate component, no?

> > Wheres the problem? yes, by default you have to lookup > > each call in a table. for speed, to inline the primitives, > > Would that really be faster than the current interpreter? Just a > bit, I think. Is that worth the effort? >

Huh, just only a bit?

> > there is a need for hotspot-style compilers. or marking > > never-changing code by hand ("compile func"). (like

<<quoted lines omitted: 8>>

> most powerful language --- you have speed, and you have a powerful > high level language.

whatever in rebol-like style, whatever making it faster ... :-)

> > if bind is allways bind/copy this works. note we have early binding in rebol, > > which gives very good hints what will be called (can be reduced to indirect addresses IMO).

<<quoted lines omitted: 5>>

> those, you get a dramatic speed improvement with just a little > effort.

sounds interesting, is it achievable? What would such "dialect" look like, what exactly should be its purpose? Could you explain a little bit, please? Thanks, -pekr-

[34/48] from: al:bri:xtra at: 13-Sep-2000 22:22

Gabriele wrote:

> > But then again you need the compiler in the runtime; I have doubts that

such a "REBOL compiler" could be dramatically faster than the current interpreter. If you, instead, express the speed critical parts with an ad hoc designed compilable dialect, and then compile those, you get a dramatic speed improvement with just a little effort. pekr wrote:

> sounds interesting, is it achievable? What would such "dialect" look like,

what exactly should be its purpose? Could you explain a little bit, please? I could imagine an assembler dialect something like: stuff: 1234 ASM [ lda Stuff add 1 ... ] That could be interesting in Rebol/Command, arbitrary binary code in a script. Andrew Martin Not Gabriele... ICQ: 26227169 http://members.ncbi.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

[35/48] from: petr:krenzelok:trz:cz at: 13-Sep-2000 13:15

[Al--Bri--xtra--co--nz] wrote:

> Gabriele wrote: > > > But then again you need the compiler in the runtime; I have doubts that

<<quoted lines omitted: 12>>

> ... > ]

but such code is not multiplatform then. You can implement above using /Command and its /Library component. I like Tao technology - Virtual Processor code, abstraction over CPU. :-) Our VP is entire REBOL executable. I think Gabriele thought of anything else - some rules to make our code compillable or something along the lines, but no platform dependant... Let's just add compile dialect (whatever it means, but not breaking platform independency :-), together with tasking, modules, also add some funcs to perform some matrice operations upon image! datatype to view to have faster & many more effects, allow us to combine (load upon request) components (e.g. Command & View), simply concentrate more on core technology ... and ... we will be ahead ... -pekr-

[36/48] from: agem:crosswinds at: 13-Sep-2000 17:00

[g--santilli--tiscalinet--it] wrote on 13-Sep-2000/11:36:49+2:00

> [agem--crosswinds--net] wrote: > > > Compiling the compiler into the runtime? Compilers can be small.. > > Even if it has to be smart enough to compile REBOL? >

hehehe. yes. i expect compiling rebol is not that a great project. Carl has looked for speed, that means, the way rebol-code -> accociated native code will be clever&smart short. and that means, inlined it may be short to.. if i refect on GC-Bug not fixed this long time.. may mean this would need deep changes.

the stupid inliners in simple forthes doubled speed against the interpreters. on older not so prefetchy superscalar processors. hm. lets calculate. newest high-performance-chips: 20-step-pipeline. time for static branches/calls: resolved early in pipeline, clever prefetchers, may go till 0. time for often used functions like add, sub ..: parts of a cycle. one can prefetch value for next call at start of the first call, AFAIK doubled speed on apples 68K-interpreter. but: number of available registers on standart: 8. enough for tricks? Could mean 20 cycles per rebol-instruction for filling pipeline + 1/x for real calculating on interpreters. without optimisations..

> > there is a need for hotspot-style compilers. or marking > > never-changing code by hand ("compile func"). (like

<<quoted lines omitted: 5>>

> ; compilable REBOL dialect here > ]

that i mean with marking by hand. hotspot-compilers do this marking at runtime, analysing if a word can be changed with current code. if new code comes, they have to de-optimize (sun is pretty proud about that). purpose: you can write "open" components which can be extended, but if you don't extend, they will be as fast as [make native!] ("final" in java). this may be hard to check in rebol, where names can be created on the fly. but it was designed for self, smalltalk.. lie languages. self is prototype-based.. nearly as hard to optimize as rebol? an interesting aproach would be to compile whole modules, then [make component! [a: none .. ] ] instead of [make native!] :)

> where you can speed up critical code. That would make REBOL the > most powerful language --- you have speed, and you have a powerful

<<quoted lines omitted: 9>>

> those, you get a dramatic speed improvement with just a little > effort.

See expectation above for special cases (few time spend in native libraries). these cases include image-processing, which may be interesting in rebol.

> > i know SM-code is possible, but is it usefull? > > It can be. You have the power, but have to use it with wisdom. >

not without pc/returnstack-access IMO. otherwise i can replace te whole function instead of modifying it.

> > make a block-entry big enough for some usefull code, > > like add, if, .. and of course indirect call . if

<<quoted lines omitted: 7>>

> The "COMPILE ..." or "MAKE NATIVE! ..." solution seems to me much > simpler and useful.

I think too.

> > Can't be long until he thinks that job can be done > > by Rebol too. if he changes the language a bit.. If > > 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. 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..

> If RT just includes some kind of fast "byte code" interpreter or > compiler, then the compiler from the dialect to teh byte code can > be easyly done in REBOL. It's much simpler, isn't it? >

i expect it has kind of "bytecode". i would call it wordcode . stored rebol contains native addresses, which can simply lookupt and jumped to. this way better especially in calling other REBOL-functions, and having fixed-size code-parts.

> Just IMHO, > Gabriele. > -- > Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer > Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/ >

of course IMO too. Otherwise I would write REBOL :) last note: the /library -interface of /command looks like an interesting dialect for better optimisation (fixed types -> fixed offsets in objects). joined with [make component!], for special speed-parts i could accept strong typing.. oops, another last note: i have no real need for more speed till now!! Wow! but i like compilers - techniques :) Volker

[37/48] from: rishi:picostar at: 13-Sep-2000 11:39

is there any other way, besides writing a compiler, to hide source code? Rishi

[38/48] from: ryanc:iesco-dms at: 13-Sep-2000 13:37

[rishi--picostar--com] wrote:

> is there any other way, besides writing a compiler, to hide source code? > > Rishi >

Yes, but how well is the question. This would have hardcoded into REBOL to be worthwhile, although only minor changes. It would be a good deal thinner than most other programming languages, but at least provide a thin layer of protection. I am sure RT has the scheme already, but it is my guess that they want to keep things open source for the time being. Why? For one it makes REBOL is easier to learn when you can look at other peoples code. Another big point is its also simpler to deal with only text REBOL, instead of the interoperability issues that would be desired with both types out there. --Ryan Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 The Tao that can be expressed is not the eternal Tao. -Lao Tzu

[39/48] from: jhagman:infa:abo:fi at: 14-Sep-2000 14:57

Quoting [civicminded4--yahoo--com] ([civicminded4--yahoo--com]):

> > Whatever happened to the SHERMAN compiler, that I see, but cannot > get, when I do a search of the web for REBOL?

I don't really know. I asked about Sherman a few weeks back on this list as I was looking for it but got no useful answers about where it might be found. Yours, Jussi -- Jussi Hagman CS in �bo Akademi University Studentbyn 4 D 33 [juhagman--abo--fi] 20540 �bo [jhagman--infa--abo--fi] Finland

[40/48] from: jhagman:infa:abo:fi at: 14-Sep-2000 15:38

Quoting [Al--Bri--xtra--co--nz] ([Al--Bri--xtra--co--nz]):

> ASM [ > lda Stuff > add 1 > ... > ]

Hmmm... Looks like 6502 assembler. The processor that powered the Terminator. No, I'm not kidding. Just watch carefully the next time you see the movie :) Yours, Jussi -- Jussi Hagman CS in �bo Akademi University Studentbyn 4 D 33 [juhagman--abo--fi] 20540 �bo [jhagman--infa--abo--fi] Finland

[41/48] from: g:santilli:tiscalinet:it at: 14-Sep-2000 16:31

[Petr--Krenzelok--trz--cz] wrote:

> > > Compiling the compiler into the runtime? Compilers can be small.. > > > > Even if it has to be smart enough to compile REBOL? > > IF Rebol would be properly modularized, e.g. much earlier discussion about one and only > /Core.exe, others as loadable components, or just ability to 'package appropriate components into > one .exe, even compiler could be separate component, no?

You can't know what the input to compile will be, so you'll have to include everything.

> > Would that really be faster than the current interpreter? Just a > > bit, I think. Is that worth the effort? > > Huh, just only a bit?

Yup. The compiler doesn't know that IF means if, does it?

> > But then again you need the compiler in the runtime; I have dubts > > that such a "REBOL compiler" could be dramatically faster than the

<<quoted lines omitted: 4>>

> sounds interesting, is it achievable? What would such "dialect" look like, what exactly should be > its purpose? Could you explain a little bit, please?

Imagine you have the ability to MAKE NATIVE! passing a binary containing the (relocatable) machine code. You can easily write a compiler in REBOL that takes some language (even C) and translates it to machine code. Something like: my-native: make native! compile { for (int i=1; i<=10; i++) { sum += i; } } (Let's ignore argument passing etc.). Or you could use a REBOL dialect: my-native: make native! compile [start [integer!] end [integer!] /local sum [integer!]] [ for i 1 10 1 [ sum += i ] return sum ] For platform independency, you'd need to compile to some form of bytecode. Also, the compiler could be native in REBOL, so you'd be able to write: my-native: make native! [...] [...] etc. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

[42/48] from: g:santilli:tiscalinet:it at: 14-Sep-2000 16:36

[Petr--Krenzelok--trz--cz] wrote: [...]

> but such code is not multiplatform then. You can implement above using /Command > and its /Library component. I like Tao technology - Virtual Processor code, > abstraction over CPU. :-) Our VP is entire REBOL executable. I think Gabriele > thought of anything else - some rules to make our code compillable or something > along the lines, but no platform dependant...

Indeed, we need some form of "virtual processor"; but in theory RT could add in every version of REBOL a compiler for its target processor. Of course this is unlikely to happen... Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

[43/48] from: grantwparks:y:ahoo at: 14-Sep-2000 8:05

I'm not the only one! I used to program AppleII+ assembler and recognized that the 1st time I saw the movie. --- [jhagman--infa--abo--fi] wrote:

[44/48] from: g:santilli:tiscalinet:it at: 14-Sep-2000 17:12

[agem--crosswinds--net] 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)

<<quoted lines omitted: 8>>

> 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

<<quoted lines omitted: 3>>

> (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 <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

[45/48] from: g:santilli:tiscalinet:it at: 14-Sep-2000 17:19

[rishi--picostar--com] wrote:

> is there any other way, besides writing a compiler, to hide source code?

Encryption. But that needs to be supported natively in REBOL... Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

[46/48] from: ryanc:iesco-dms at: 14-Sep-2000 11:01

> [rishi--picostar--com] wrote: > > > is there any other way, besides writing a compiler, to hide source code? >

There is possibly another way I overlooked. This is to create native executable that basically has your scrambled program append to it. This executable would: 1. Display a user defined splash screen. 2. Descramble your program using a predefined key. 3. Verify the REBOL executable is indeed the real thing and not a fake. 4. Execute REBOL with special command line disabling escape key and executing your program via stdin. Now I said possibly. What I dont know is if you can disable the escape key, or execute programs in the usual way via stdin. If it does work, also take in mind that this still a very thin layer of security. There is no need to use very strong encryption since a hackers have all the elements they need to decrypt. But if they know that much, they might just prefer to write thier own version of your program from scratch. --Ryan Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 The Tao that can be expressed is not the eternal Tao. -Lao Tzu

[47/48] from: al:bri:xtra at: 15-Sep-2000 17:22

> Quoting [Al--Bri--xtra--co--nz] ([Al--Bri--xtra--co--nz]): > >

<<quoted lines omitted: 4>>

> > ] > Hmmm... Looks like 6502 assembler. The processor that powered the

Terminator. No, I'm not kidding. Just watch carefully the next time you see the movie :) 680x actually, IIRC. It's been a while. Andrew Martin ICQ: 26227169 http://members.ncbi.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

[48/48] from: jhagman:infa:abo:fi at: 18-Sep-2000 3:09

Quoting [Al--Bri--xtra--co--nz] ([Al--Bri--xtra--co--nz]):

> > Quoting [Al--Bri--xtra--co--nz] ([Al--Bri--xtra--co--nz]): > > >

<<quoted lines omitted: 8>>

> the movie :) > 680x actually, IIRC. It's been a while.

I stand corrected. Actually 6502 does not have instruction ADD... How silly of me for not remembering :) -- Jussi Hagman CS in �bo Akademi University Studentbyn 4 D 33 [juhagman--abo--fi] 20540 �bo [jhagman--infa--abo--fi] Finland

Notes

Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted