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

Compiler for Rebol ?

 [1/52] from: youpi:technologies:wanadoo at: 23-Sep-2000 20:22


I heard about a compiler for Rebol. Is it still available because how can you deliver application to client if there isn't any kind of code protection ? @ ----- Message d'origine ----- De : <[pa--russo--perd--com]> À : <[list--rebol--com]> Envoyé : vendredi 22 septembre 2000 17:05 Objet : [REBOL] Why I'll pay for REBOL/command (or not). Was - Will REBOL/View be commercial?

 [2/52] from: al:bri:xtra at: 24-Sep-2000 10:19


[youpi--technologies--wanadoo--fr] wrote:
> I heard about a compiler for Rebol. Is it still available...
That's Sherman. It's a compiler for an old version of Rebol. I believe it won't work for recent versions of Rebol.
> because how can you deliver application to client if there isn't any kind
of code protection? With Rebol/Command, this might not be an issue, as it's more a CGI and in house tool, I believe. For Rebol/View, this doesn't seem to be an issue, because the source code is stored at a URL. This operates much like HTML pages and JavaScript on the web does currently. Organisations pay people to write HTML, JavaScript, Java and to design .gif, .jpeg and Flash graphics, yet piracy of the "code" isn't really a problem, because the "code" is embedded in the content. For stand-alone, shrink-wrapped client use, like RebMail, a email client, or similar programs, I can imagine that a future Rebol product would a Rebol/View or Rebol/Core that can be packaged with a number of encrypted scripts into one executable binary. That seems fairly obvious to me. I've also CC-ed this to [feedback--rebol--com] just in case the Rebol crew haven't thought of it yet. Andrew Martin ICQ: 26227169 http://members.ncbi.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

 [3/52] from: petr:krenzelok:trz:cz at: 24-Sep-2000 0:50


> For stand-alone, shrink-wrapped client use, like RebMail, a email client,
or
> similar programs, I can imagine that a future Rebol product would a > Rebol/View or Rebol/Core that can be packaged with a number of encrypted > scripts into one executable binary. That seems fairly obvious to me. I've > also CC-ed this to [feedback--rebol--com] just in case the Rebol crew haven't > thought of it yet.
I think some ideas were expressed for many times here on ml. I also think RT thought about it already, the question is if they will regard it being priority. Let's face it: Some time ago Carl mentioned something about partial compilation of certain expression. Just few weeks ago he thowed here one email stating something like why don't you guys use 'compile? Hey ;-) With no further explanation following, one can only guys Carl is somethin cooking on his notebook, or I just misuderstood the issue. Elan, in one of his last posts (as reaction to my email of disappointment), talked about slim binaries. If I am not wrong, slim binaries are kind of multiplatform binaries. New Amiga OS will have the same advantage. Once app will be in VP code, you can transfer the file between platforms. I don't know how efficient the solution could be with interpreted language, if it would be some kind of byte code or what, but could be interesting ... Then there is a possibility of REBOL runtime. Well, that's something I would like to see as the last option. Why? Because this way RT has to maintain another family of REBOL versions, limiting the language. I would like to see freedom of expression. E.g., some scripts (modules) in compiled form (slim "binary", byte-p-code, whatever), while end user ability to influence some of the other scripts (modules) ... Some one or two years ago, there was also talk about so called REBOL/Toolkit - REBOL in the form of libraries, embeddable into another language apps ... Cheers, -pekr-

 [4/52] from: jsc:dataheaven at: 24-Sep-2000 1:15


I think CodeSecurity through compiling is nonsense. You should compile something to make it running faster, not to make sure nobody can read your secrets. If someone really is interested in your code - a compiler doesn't protect you. If you say "But it's a great efford to disassemble and reengineer compiled code and nobody will do that" then your code isn't really worth to protect it. IMHO 99.99% of the nowadays written code isn't worth protecting it. The little amount of code that is really sophisticated and valueable would need to be protected by stronger means. But why? IMHO I think it is ridiculous to think that "Open Source" projects can be cloned by each newbie-programmer. A open-sourced project that offers really sophisticated code is not easy to understand and therefore not easy to clone. If someone has the ressources to (legally) clone such a complex project, he would certainly have also the resources to rewrite it from scratch. Open Source is a important quality-characteristic. If I can choose between a opensource application and a closed-source application? You know what I would choose. Is it so that with Open Source projects all people begin to clone the software and not buying it? I do not want to write my own webserver - I simply use Apache and I know that the good folks that develop this tool will make a far better job than I could do. If I charge a software-team to develop a special software for me, I certainly want the source too! Such a software will cost me ~ 100$ per man-hour!!! Regards, Jochen Schmidt On Sun, 24 Sep 2000, you wrote:

 [5/52] from: jsc:dataheaven at: 24-Sep-2000 1:29


I would prefer a more Lisp-like way of compiling. In Lisp compiling is only for gaining speed and make smaller code-units. In Lisp - similar to REBOL - you can inspect the not native functions at runtime. (in compiled code too!!) So there compilation would be no real protection. History shows that applications written in CommonLisp are solving highly complex tasks e. g. the NASAs Pathfinder-Mission-Planning tool was written in CommonLisp. Although the code is accessible at runtime (and so somewhat "open") CommonLisp applications are sold for huge amounts of money. Yahoo has bought some months ago a CommonLisp application for ~50 Mio $ All customers using CommonLisp say they love the ability to change code in a running application. This is also possible with REBOL and we should not loose it through a compiling feature that hinders us in access to compiled REBOL code. Regards Jochen Schmidt On Sun, 24 Sep 2000, you wrote:

 [6/52] from: al:bri:xtra at: 24-Sep-2000 11:22


pekr wrote:
> Some time ago Carl mentioned something about partial compilation of
certain expression. Just few weeks ago he thowed here one email stating something like why don't you guys use 'compile? Hey ;-) With no further explanation following, one can only guess Carl has somethin' cooking on his notebook, or I just misunderstood the issue. I couldn't find 'compile anywhere! :-( ;-)
> Elan, in one of his last posts (as reaction to my email of
disappointment), talked about slim binaries. If I am not wrong, slim binaries are kind of multiplatform binaries. New Amiga OS will have the same advantage. Once app will be in VP code, you can transfer the file between platforms. I don't know how efficient the solution could be with interpreted language, if it would be some kind of byte code or what, but could be interesting ... I think encrypting a bunch of scripts and then decrypting them only in the computer's memory, should provide a reasonable way to ensure security of scripts.
> Then there is a possibility of REBOL runtime. Well, that's something I
would like to see as the last option. Why? Because this way RT has to maintain another family of REBOL versions, limiting the language.
> I would like to see freedom of expression. E.g., some scripts (modules) in
compiled form (slim "binary", byte-p-code, whatever), while end user ability to influence some of the other scripts (modules) ... I think a Rebol runtime is a good idea, along with encrypted scripts.
> Some one or two years ago, there was also talk about so called
REBOL/Toolkit - REBOL in the form of libraries, embeddable into another language apps... That was the Rebol DLL. It's still a possibility. As for Rebol crew's work load, they all ready provide binaries for 40+ different OS. An encryptor/decryptor module, once it's working OK, shouldn't be too much of a problem, I would think. Andrew Martin ICQ: 26227169 http://members.ncbi.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

 [7/52] from: tim:johnsons-web at: 23-Sep-2000 16:14


MTCW: Where I live, I know two kinds of programmers: 1)Self-employed curmudgeons like myself. 2)Programmers for large organizations, like government, municipalities. When I talked to members of 1) about rebol, they said things like "wow", "cool", "check it out!". When I talked to members of 2) about rebol, those folks asked questions like: "Is it compilable?" and "Is it embeddable?". For what it is worth... Tim

 [8/52] from: joel:neely:fedex at: 23-Sep-2000 23:54


Hi, Jochen! [jsc--dataheaven--de] wrote:
> I think CodeSecurity through compiling is nonsense. >
Bit harsh. Not nonsense, just not a perfect solution against a well-equipped, knowledgeable attacker.
> You should compile something to make it running faster...
Agreed that this is another advantage.
> ... not to make sure nobody can read your secrets. >
How about, "To make it difficult enough that fewer will do so, and to reduce the risk of alterations (accidental or otherwise) of the source which can create stability/support problems."
> If someone really is interested in your code - a compiler doesn't > protect you. >
If that someone is sufficiently skilled and has sufficient resources and time, agreed. But not everyone fits those criteria.
> Open Source is a important quality-characteristic... >
Open source development (if properly managed) is certainly an effective process for producing high-quality code. Even the Forrester group agrees with that (much to my amazement!)
> If I charge a software-team to develop a special software for me, > I certainly want the source too! Such a software will cost me > ~ 100$ per man-hour!!! >
And if you're paying them to develop custom software for you, it is certainly reasonable for you to establish as a condition of the contract that you get the source (or at least have access to it in the event of a failure on their part). However, there's more to the software market than bright people such as yourself contracting with high-priced developers for the construction of custom code. BOTTOM LINE: As has been pointed out in the recent "40 platforms" thread, there's a real marketplace out there. While Carl and company would be within their legal/moral/whatever rights to stop supplying REBOL for w95/98/nt/2k (just to use a hypothetical and totally unlikely example ;-), I'd consider that an impractical decision if the goal is to get REBOL widely adopted. Similarly, although I applaud/appreciate the legions of excellent developers who contribute to the open source movement, and am a grateful beneficiary of their labors, I question the practicality of refusing to address the concerns of developers who wish to have some other means of distribution than pure source code -- for a variety of reasons. -jn-

 [9/52] from: jsc:dataheaven at: 24-Sep-2000 7:50


On Sun, 24 Sep 2000, you wrote:
> Hi, Jochen! > > [jsc--dataheaven--de] wrote: > > I think CodeSecurity through compiling is nonsense. > > Bit harsh. Not nonsense, just not a perfect solution against a > well-equipped, knowledgeable attacker.
Hm my harsh tone seems to be a real problem ... ;-) But I think compared with the other thread this is much lesser harsh ! ???
> > ... not to make sure nobody can read your secrets. > > How about, "To make it difficult enough that fewer will do so, > and to reduce the risk of alterations (accidental or otherwise) > of the source which can create stability/support problems."
To ensure the risk of alterations we could also use checksums with our scripts. So that a script can abort after checking it's checksum. This will help out with accidental alterations. (Compiled code can also crash when modified!) The problem with "other" (user?) alterations is a bit more difficult. As a vendor I would reject all warranty-claims if a client modifies the product. To check this we could again use checksums of the distributed files.
> > If someone really is interested in your code - a compiler doesn't > > protect you. > > If that someone is sufficiently skilled and has sufficient resources > and time, agreed. But not everyone fits those criteria.
This is why I said that it is a sign that the code isn't worth the whole protecting-thing if theres no one that throws in the ressources to reverseengineer it.
> > Open Source is a important quality-characteristic... > Open source development (if properly managed) is certainly an
<<quoted lines omitted: 10>>
> such as yourself contracting with high-priced developers for the > construction of custom code.
It was only a example - I work as Softwaredeveloper at a softwarevendor that creates e. g. software for airports,Air Information Services, traveling-agencies and more. Most of our profit is made through custom applications. 100$ per man-hour is not to much for such work. Most projects cost in the range of some 100k$.
> BOTTOM LINE: As has been pointed out in the recent "40 platforms" > thread, there's a real marketplace out there. While Carl and
<<quoted lines omitted: 8>>
> some other means of distribution than pure source code -- for a > variety of reasons.
I think I have to explain a little more what I meant. I did not say RT should stop supplying Win.. Platforms with their fantastic tools!!! It is important for RT and the REBOL-Comunity that REBOL evolves to a widely used language. What I said was much more general than it obviously seemed. IMHO there exist NO OS I really like. UN*X is the worst OS - besides all the other ;-) I've dreams of what a OS should look like. But no Vendor seems to try to evolve in those directions. As you certainly agree the net is one of the most important things in the future. We are in the beginnings - There is _much_ more possible. The Problem is that the Microsoft-Way (And the Apple Way too!!!) hinders the development of that future. They develop Desktop OSs why should they work toward a more networked future??? Sun is in another situation. They sell servers - so they try to let the network grow more. But there are other reasons why Sun hinders the development too. In relation to to the Open Source topic: IMHO most developers should more think of what source they can protect than what sources to Open. This sounds irritating but if they open most of their code by default and only some little (real valuable) code is protected this would led to a much better situation. What I wanted to say is "Hey Guys look at your Software! Is it REALLY SOOOOO special, sophisticated and valuable that it have to be protected?" I hope this explaines a little bit more what I wanted to say. Regards, Jochen Schmidt

 [10/52] from: news:ted:husted at: 24-Sep-2000 7:06


On 9/23/2000 at 4:14 PM [tim--johnsons-web--com] wrote:
> 1)Self-employed curmudgeons like myself. > 2)Programmers for large organizations, like government,
municipalities. And then there's someone like me, a self-employed curmudgeon who contracts with larger organizations, who says "wow" or "is it" depending on whether it's for me or another organization. -T/ *********** REPLY SEPARATOR *********** MTCW: Where I live, I know two kinds of programmers: 1)Self-employed curmudgeons like myself. 2)Programmers for large organizations, like government, municipalities. When I talked to members of 1) about rebol, they said things like "wow", "cool", "check it out!". When I talked to members of 2) about rebol, those folks asked questions like: "Is it compilable?" and "Is it embeddable?". For what it is worth... Tim

 [11/52] from: news:ted:husted at: 24-Sep-2000 7:08


On 9/24/2000 at 1:15 AM [jsc--dataheaven--de] wrote:
> IMHO I think it is ridiculous to think that "Open Source" projects
can be cloned by each newbie-programmer. This is an important point. What many people who write code overlook is that the marketplace still considers software applications an investment (as opposed to a disposable commodity). They are not just buying the software product that is shipping today, but the support and upgrades that go with it. The reason so many products are going open source now is because people realize that the source really isn't worth that much. The world is full of source. The value is with the organization or community that distributes and supports the software. Source is a commodity; Products are an investment. If MS released the source for Excel, people would still rather buy the official distribution for $50 or $100 then pay less from an unknown source. This is one reason Sun's StarOffice isn't taking the corporate world by storm -- there isn't a lot of desktop support in place for the product, and that's where people spend the real bucks - training and customization. -Ted.

 [12/52] from: news:ted:husted at: 24-Sep-2000 7:15


On 9/24/2000 at 10:19 AM [Al--Bri--xtra--co--nz] wrote:
> yet piracy of the "code" isn't really a problem
Has it ever been a real "problem"? (Damages you could prove.) Or just a bogey-man? -Ted.

 [13/52] from: siegel:prodigy:mx at: 24-Sep-2000 6:50


At 07:08 a.m. 24/09/00 -0400, you wrote:
>This is one reason Sun's StarOffice isn't taking the corporate world by >storm -- there isn't a lot of desktop support in place for the product, >and that's where people spend the real bucks - training and customization.
I tried it. It's kind of clunky and weird but intriguing. Some of the labels are still in a foreign language. First I thought it was German, but I think it's Norwegian. The default spell check language is Norwegian. It does strange things, such as substituting "/" if you type "--", and it's hard to find out why or how to change it. I think that if there were full attention to these details it would be very successful, as there is a lot to like about the product. It is surprisingly useful for web page design, for example, but the weird aspects made me leave it after a while. -- JULES SIEGEL Apdo 1764 Cancun Q. Roo 77501 http://www.cafecancun.com Fax1.530.706.8739 Tel 1.52.98 83.36.29

 [14/52] from: joel:neely:fedex at: 24-Sep-2000 8:07


[news--ted--husted--com] wrote:
> On 9/23/2000 at 4:14 PM [tim--johnsons-web--com] wrote: > > 1)Self-employed curmudgeons like myself.
<<quoted lines omitted: 3>>
> contracts with larger organizations, who says "wow" or "is it" > depending on whether it's for me or another organization.
And then there are just plain cranky old goats like me, who will in a typical day/week be using HP-UX, Solaris, Linux, MacOS, and a growing list of "W" variations -- who is TOTALLY FED UP with having to write the same code more than once, whether its for day-pay, private consulting, volunteer work, personal enjoyment, self-education, or whatever. Which is why any tool that is not supported on every platform I routinely use (or may [have to] use in the future) is of little interest to me. (Even though circumstances may force me to be flexible on occasion ;-) -jn-

 [15/52] from: joel:neely:fedex at: 24-Sep-2000 8:36


[jsc--dataheaven--de] wrote:
> On Sun, 24 Sep 2000, you wrote:
...
> > BOTTOM LINE: As has been pointed out in the recent "40 platforms" > > thread, there's a real marketplace out there. While Carl and
<<quoted lines omitted: 13>>
> that REBOL evolves to a widely used language. > What I said was much more general than it obviously seemed.
My reference to msxxx was only an analogy. Let me try to do better at drawing the parallel: Regardless of what I think of Regardless of what I think of a the Windows environment, there Closed-Source approach, there are many people who prefer it are many people who prefer it or who have constraints that or who have constraints that force them to use it. force them to use it. Any language that fails to Any language that fails to address their desires/needs address their desires/needs will limit its acceptance. will limit its acceptance. Regardless of my personal Regardless of my personal views on that environment, I views on that approach, I believe the language designer believe the language designer should consider the desires/ should consider the desires/ needs of the group above, or needs of the group above, or risk limiting his language's risk limiting his language's growth and acceptance. growth and acceptance. As long as his support for As long as his support for that environment doesn't that approach doesn't FORCE ME to use it when I FORCE ME to use it when I choose not to. choose not to. Carl's support for MS operating systems doesn't keep me from using any of several varieties of Unix/Linux (except Debian, but that's another issue!), MacOS, etc. If Carl chose to give us a way to compile, tokenize, convert-to- byte-code, or whatever, as a way to deliver executable REBOL scripts in a form that does not immediatly disclose the source code (whatever the reaons!), that wouldn't keep anyone who wished to do so from supplying source code.
> What I wanted to say is > > "Hey Guys look at your Software! Is it REALLY SOOOOO > special, sophisticated and valuable that it have to be > protected?" >
A perfectly fair question for a discussion such as this. But I don't think anyone else has to answer it to my satisfaction before being allowed to protect it. What I wanted to say to RT is "Hey guys! Is it really so important to force all developers to give out their source code that you won't provide any alternatives?"
> I hope this explaines a little bit more what I wanted to say. >
And, of course, all of the above discussion ignores other quite legitimate reasons for wanting some sort of pre-processed form of code: performance (which you mentioned in an earlier post), reduced run-time overhead (no need to parse/translate/compile, potentially fewer moving parts in the distributed product, potentially simpler set up, etc.), simpler/faster distribution ("object" is typically smaller than "source", making it faster to download/copy/install, etc.) and so on... Thanks! -jn-

 [16/52] from: news:ted:husted at: 24-Sep-2000 9:44


On 9/24/2000 at 6:50 AM [siegel--prodigy--net--mx] wrote:
> I think that if there were full attention to these details it would
be very successful, as there is a lot to like about the product. It is surprisingly useful for web page design, for example, but the weird aspects made me leave it after a while. StarOffice's greatest strength and weakness is the tight integration between applications. On one hand, the applications can work together in surprizing and useful ways. On the other, it works against the idea of someone assembiling their own "best of breed" suite of applicatoins. But it would seem a good choice where people are trying hard to standardize their corporate desktops. To give the devil its due, I think the Win32 desktop is a marvelous example of integrating applications into a useful work environment. (Now, if only the underlying OS wasn't broken.) -Ted.

 [17/52] from: jsc:dataheaven at: 24-Sep-2000 17:31


On Sun, 24 Sep 2000, you wrote:
> At 07:08 a.m. 24/09/00 -0400, you wrote: > >This is one reason Sun's StarOffice isn't taking the corporate world by
<<quoted lines omitted: 5>>
> does strange things, such as substituting "/" if you type "--", and it's > hard to find out why or how to change it.
Hm.. it maybe because I'm German (and StarDivision was a German Vendor) but I've nto seen such behavior in last releases. Have you ever tried the 5.2 release? (A whole bunch of changes) I like the high grade of integration. Furthermore it has the best formula-editor I ever seen in a wordprocessor. Regards Jochen Schmidt

 [18/52] from: jsc:dataheaven at: 24-Sep-2000 18:07


> As long as his support for As long as his support for > that environment doesn't that approach doesn't > FORCE ME to use it when I FORCE ME to use it when I > choose not to. choose not to.
Right, thats my opinion too, but by using compile to hide the source we would loose the ability to acces code at runtime of compiled code. Coming from CommonLisp I think this would be very bad - we would give away a really important feature!
> Carl's support for MS operating systems doesn't keep me from > using any of several varieties of Unix/Linux (except Debian, but > that's another issue!), MacOS, etc.
I never said something against this fact.
> > I hope this explaines a little bit more what I wanted to say. > And, of course, all of the above discussion ignores other quite
<<quoted lines omitted: 5>>
> ("object" is typically smaller than "source", making it faster > to download/copy/install, etc.)
Yes that's the point! _I_ would prefer using compilation (native, bytecode or whatever) for making the code more efficient and smaller. But I do _not_ want to loose runtime accessibility to the code. Regards, Jochen Schmidt

 [19/52] from: tim:johnsons-web at: 24-Sep-2000 8:50


Hi: I see that we have taken a thread more about strategy and marketing here, and I hope rebol team people are reading this. Interesting thing coming up here... I think. Koffice (KDE answer to Microsoft Office) is supposed to provide hooks to a number of languages, rather than a proprietory VBA as does MS-Office. Perhaps Carl and folks should consider looking into this and perhaps trying to make sure that Koffice provides such "hooks" for rebol. I could sure "dig it". It is reasonable to speculate that in the next year, in the area that I live in we will see a number of networks of small organizations running Windows on top of Linux through something like Win4Lin. With KOffice there would then be a cheaper alternative to Microsoft's expensive Office license. It then follows that a considerable amount of small-module programming would happen. I'm already putting together General Purpose modules for Ms-Access using VBA. I'd rather be doing that in rebol! :) -Tim [news--ted--husted--com] wrote:

 [20/52] from: joel:neely:fedex at: 24-Sep-2000 12:24


[jsc--dataheaven--de] wrote:
> Right, thats my opinion too, but by using compile to hide the > source we would loose the ability to acces code at runtime of > compiled code. Coming from CommonLisp I think this would be > very bad - we would give away a really important feature! >
I don't want to belabor this point unnecessrily (I probably have!), but I do NOT agree with casting this issue as a value judgement over an option which other languages provide the developer. If you (or your company) takes the policy position that you will never buy/license any software that comes without source, that's your right! (And if that means that you therefore can't use some products because they don't come with that option... well, you had the choice, so you get the consequences.) EQUALLY IMPORTANT IS THE DEVELOPERS RIGHT TO CHOOSE... If some developer creates a product for which he/she chooses not to distribute the source, that's his/her right! (And if that means that she/he loses some sales to people who require source as a precondition... well, she/he had the choice, so she/he gets the consequences.) EITHER WAY, that's what free markets are about. But to pre-empt EITHER the consumers' or developers' rights to choose how they will do business by creating a development environment (or a political environment or an economic one...) that gives all the rights of choice to one party (or by institutionalizing that party's choice so that it isn't even a choice any longer) is to prevent the market from working such things out on a case by case basis -- which I believe to be the fairest mechanism in the long run.
> > Carl's support for MS operating systems doesn't keep me from > > using any of several varieties of Unix/Linux (except Debian, but > > that's another issue!), MacOS, etc. > > I never said something against this fact. >
You didn't, and I didn't mean to imply that you had. I was using the "choice of O/S" issue (which I think we all agree is a Good Thing) to try to illustrate why I think the choice of distribution form is also a Good Thing.
> _I_ would prefer using compilation (native, bytecode or whatever) > for making the code more efficient and smaller. >
And I wholeheartedly support any steps which allow you that choice!
> But I do _not_ want to loose runtime accessibility to the code. >
And that, also, is your choice. You have a perfect right to make that a condition of doing business with you. However, I don't support making that a constraint on how everybody can conduct their affairs, when they are NOT doing business with you. That's THEIR choice! -jn-

 [21/52] from: lmecir:geocities at: 24-Sep-2000 22:01


Well, let me throw in some thoughts. I think, that the debate started to look more abstract than I prefer. My comments are: 1) Rebol is IMHO designed with the runtime code accessibility in mind (inspired by Lisp), so I do not think, there's an easy way to convert that feature to its opposite. 2) I prefer the speed when compilation is considered, the source code protection is only a minor effect surely achievable by more direct means (discussed by Joel some time ago). 2a) When I look at the development in processor speeds (GHz looking as standard for year 2001 processors) and the neverstopping need to increase processor speeds, it is surely less preferable to write programs 100 or more times slower than C in some cases, so the speed is something any language including Rebol could use. 2b) Rebol with its mutable values used to store code radically differs even from Lisp, that uses immutable series for that AFAIK. That fact has immediate consequences - Self Modifying Code looks as standard - even some basic Rebol constructs are modifying, eg: 2ba) Use - modifies its (code) block argument (this causes even "unexpected" behaviour when recursive functions are called) and causes its code block argument very hard to compile when speed is the goal 2bb) Make object! - modifies its (code) block argument - see above 2bc) Bind - modifying, as opposed to Bind/copy, which behaves better 2bd) any mutables contained in the code aren't protected against change - no compilation advantage 2be) the code block can easily modify itself - a feature making compilation almost impractical Not trying to criticize, just to discuss the possibilities. What do you think? Ladislav

 [22/52] from: siegel:prodigy:mx at: 24-Sep-2000 15:30


At 05:31 p.m. 24/09/00 +0200, you wrote:
>Have you ever tried the 5.2 release? (A whole bunch of changes)
It's a 40 mb download (I think). the last one was arduous. This is Mexico. Then comes Cancun, which is at the end of the line, believe me. I keep meaning to get the CD, but other things come first -- like a new harddrive. we run a tight ship here at Siegel & Children Third World Slave Labor Writing Industries SA de CV. -- JULES SIEGEL Apdo 1764 Cancun Q. Roo 77501 http://www.cafecancun.com Fax1.530.706.8739 Tel 1.52.98 83.36.29

 [23/52] from: news:ted:husted at: 25-Sep-2000 9:35


Under the heading compare and contrast, I would offer the following clips from the Python FAQ-o-Matic. While a popular topic for speculation, I don't believe whether or how the REBOL interpreter precompiles code has never been clarified. Of course, Carl's recent mention of the mysterious 'compile keyword implies something like this is taking place behind the scenes (and could then ultimately be exposed). --- 6.13. Can Python be compiled to machine code, C or some other language? Not easily. Python's high level data types, dynamic typing of objects and run-time invocation of the interpreter (using eval() or exec) together mean that a "compiled" Python program would probably consist mostly of calls into the Python run-time system, even for seemingly simple operations like "x+1". Several projects described in the Python newsgroup or at past Python conferences have shown that this approach is feasible, although the speedups reached so far are only modest (e.g. 2x). JPython uses the same strategy for compiling to Java bytecode. (Jim Hugunin has demonstrated that in combination with whole-program analysis, speedups of 1000x are feasible for small demo programs. See the website for the 1997 Python conference.) Internally, Python source code is always translated into a "virtual machine code" or "byte code" representation before it is interpreted (by the "Python virtual machine" or "bytecode interpreter"). In order to avoid the overhead of parsing and translating modules that rarely change over and over again, this byte code is written on a file whose name ends in ".pyc" whenever a module is parsed (from a file whose name ends in ".py"). When the corresponding .py file is changed, it is parsed and translated again and the .pyc file is rewritten. There is no performance difference once the .pyc file has been loaded (the bytecode read from the .pyc file is exactly the same as the bytecode created by direct translation). The only difference is that loading code from a .pyc file is faster than parsing and translating a .py file, so the presence of precompiled .pyc files will generally improve start-up time of Python scripts. If desired, the Lib/compileall.py module/script can be used to force creation of valid .pyc files for a given set of modules. Note that the main script executed by Python, even if its filename ends in .py, is not compiled to a .pyc file. It is compiled to bytecode, but the bytecode is not saved to a file. If you are looking for a way to translate Python programs in order to distribute them in binary form, without the need to distribute the interpreter and library as well, have a look at the freeze.py script in the Tools/freeze directory. This creates a single binary file incorporating your program, the Python interpreter, and those parts of the Python library that are needed by your program. Of course, the resulting binary will only run on the same type of platform as that used to create it. 4.93. How do I compile a Python application to a stand-alone program? Even though there are Python compilers being developed, you probably don't need a real compiler, if all you want is a stand-alone program. There are three solutions to that. One is to use the freeze tool, which is included in the Python source tree as Tools/freeze. It converts Python byte code to C arrays. Using a C compiler, you can embed all your modules into a new program, which is then linked with the standard Python modules. On Windows, another alternative exists which does not require a C compiler. Christian Tismer's SQFREEZE (http://starship.python.net/crew/pirx/) appends the byte code to a specially-prepared Python interpreter, which will find the byte code in executable. Gordon McMillian offers with Installer (http://starship.python.net/crew/gmcm/distribute.html) a third alternative, which works similar to SQFREEZE, but allows to include arbitraty additional files in the stand-alone binary as well. --- A while back, someone asked about a Java implementation of REBOL. The idea was dismissed in general since the REBOL binary is available for all Java platforms (and then some), and an imaginative Java to REBOL workaround was posted. Here's how the JPython group < http://jpython.org > justified their project: -- Embedded scripting - Java programmers can add the JPython libraries to their system to allow end users to write simple or complicated scripts that add functionality to the application. Since JPython is certified 100% Pure Java, it can be added to an application without fear of compromising its ability to run on all Java platforms. Interactive experimentation - JPython provides an interactive interpreter that can be used to interact with Java packages or with running Java applications. This allows programmers to experiment and debug any Java system using JPython. Rapid application development - Python programs are typically 2-10X shorter than theequivalent Java program. This translates directly to increased programmer productivity. The seamless interaction between Python and Java allows developers to freely mix the two languages both during development and in shipping products. -- In REBOL's case, I'd also mention that Java has support for many mundane features, like printing, that REBOL now lacks, not to mention other niceities like PDA sychronization. So if there were a jREBOL.class, and I ran into a feature-gap, I could put a Java wrapper around it and move forward. There would also be the part about distributing my application in Java bytecode, to hide the source. -Ted.

 [24/52] from: hopeless::eircom::net at: 25-Sep-2000 15:04

jREBOL (was Compiler for Rebol ? Re:(9))


> In REBOL's case, I'd also mention that Java has support for many > mundane features, like printing, that REBOL now lacks, not to mention
<<quoted lines omitted: 4>>
> bytecode, to hide the source. > -Ted.
Indeed. There is such a huge amount of API's available for Java that it seems such a shame to ignore it. On the other hand jPython (AFAIK) is mostly used for scripting java objects, in particular for embedded scripting within aplications and for testing purposes. i.e. Python->Java. Whether REBOL is suitable for this role I doubt. But with REBOL you can do things like parsing and internet functionality much easier than in Java so typically it would be useful doing Java->REBOL. This is slightly different to the typical uses of JPython (let me know if I'm completely wrong on this one). The solution suggested a while back involved running a REBOL server and using TCP/IP sockets to communicate from Java to REBOL. Imaginative but still ugly and possibly slow (I'll be trying it out soon hopefully). Ideally a Java Native Interface to REBOL would be nice but platform-specific so we can discount it. Perhaps there is no better way ;-( Jamie

 [25/52] from: jhagman:infa:abo:fi at: 25-Sep-2000 20:05

Compiler for Rebol ? Re:(6)


Quoting [joel--neely--fedex--com] ([joel--neely--fedex--com]):
> Carl's support for MS operating systems doesn't keep me from > using any of several varieties of Unix/Linux (except Debian, but > that's another issue!), MacOS, etc.
What's wrong with Debian? I am just being curious because that is the distribution I am using... - Jussi -- Jussi Hagman CS in Åbo Akademi University Studentbyn 4 D 33 [juhagman--abo--fi] 20540 Åbo [jhagman--infa--abo--fi] Finland

 [26/52] from: joel:neely:fedex at: 25-Sep-2000 14:49


[jhagman--infa--abo--fi] wrote:
> Quoting [joel--neely--fedex--com] ([joel--neely--fedex--com]): > > Carl's support for MS operating systems doesn't keep me from
<<quoted lines omitted: 3>>
> distribution I am using... > - Jussi
I arranged to make a presentation a few weeks ago to the local Linux users' group. That group meets after hours in the local headquarters of a national-scale company, with employees of that company bringing their own boxen into the auditorium and setting up network, video projection, etc. before each mtg. I had previously done a presentation on REBOL (well received BTW) using a box running RedHat 6.whatever. THIS time, the box set up for the mtg was running Debian. Both the public beta of /View and the current rlse of /Core blew up instead of running. I tap-danced furiously, and did a few minutes on XML. I didn't report it at the time because the box was actually running Debian Unstable, and assumed that maybe the guy who set it up was just a little too close to the edge. Also, it wasn't my box (and I was on the stage...) so I couldn't spend too much time poking around. Since then, I've seen traffic on this list indicating that others have had problems with REBOL on Debian, so perhaps my experience wasn't so unique or box-owner-dependent after all??? -jn-

 [27/52] from: handy:techie at: 27-Sep-2000 0:32


(im not sure if this has already been talked about but ...) You know what would be really cool? If the Rebol compiler compiled to Java bytecodes! ...now hold your horses... Apart from the obvious platform benefits (which i *know* rebol already has): 1) Theres already a lot of support for Java and all related technologies 2) Rebol could utilise some of the Java popularity<->support to bring rebol into the mainstream 3) There are native language compilers for Java bytecodes >:) (eg GCJ) -- But its just an idea ... why can i sense a flame coming my way? :) AndrewH

 [28/52] from: sharriff:aina:med-iq at: 26-Sep-2000 16:08


I can see it coming, somebody would write a wrapper or compiler for REBOL one day..... Sharriff Aina med.iq information & quality in healthcare AG Gutenbergstr. 42 41564 Kaarst tel.: 02131-3669-0 fax: 02131-3669-599 www.med-iq.de

 [29/52] from: ptretter:charter at: 26-Sep-2000 14:24


I believe the best option for the masses would be to just be able to make native! those functions that expose the performance or characteristic of the finished script. Seems the easiest approach and should accomplish the goal. Maybe the make native! function would have some algorithm that unlock the code that the programmer only knows. Do I sounds out of my mind here? Paul Tretter

 [30/52] from: al:bri:xtra at: 27-Sep-2000 8:34


Sharriff Aina wrote:
> I can see it coming, somebody would write a wrapper or compiler for REBOL
one day..... I don't know about the compiler, but the wrapper is available from Rebol now! Read what Bo sent to me: <Quote> (Regarding REBOL Helpdesk #4466) Andrew, Here is a snippet from our REBOL/Command press release: Ukiah, CA - September 21, 2000 - REBOL Technologies today announced the availability of REBOL/Command 1.0, a commercial extension to its leading Internet application development product REBOL/Core 2.3. REBOL/Command 1.0 enables developers to extend their REBOL language-based applications by integrating them with popular platform-specific libraries, tools, 3rd party applications and databases. REBOL/Command Runtime, which will be released next month, will enable developers to encapsulate their REBOL applications for distribution to their customers. By 'encapsulate', we mean that you can write a script and distribute it with the REBOL/Command binary. The source code to the script cannot be seen and the binary cannot run any scripts other than the one that is encapsulated with it and the scripts that are called from within that script. It will most likely be sold on a number-of-units-distributed license. This same scheme can easily be extended to REBOL/View and REBOL/Core should we decide to do this at some point. If you have any additional questions/comments/suggestions, please let us know! </Quote> Note the "Encapsulate" part. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

 [31/52] from: joel:neely:fedex at: 26-Sep-2000 16:11


No flaming from me; just puzzled head-scratching. It's not clear to me that REBOL and Java are conceptually close enough to be ABLE to compile REBOL directly into Java bytecode. Some REBOL features could be dealt with by defining support classes in Java, with appropriate method calls as the Java equivalent of REBOL words/phrases. However, there are REBOL features for which I don't see an obvious JVM representation. For example: 1) REBOL's refusal to distinguish between data and code, whick allows one to construct a block and then do that block, 2) REBOL's ability to manipulate contexts, 3) REBOL's class-less view of objects... It would certainly be possible to create a REBOL interpreter written in Java, but that's not what I understood you to be suggesting (and my experience with Java suggests that it would run like a pig on tranquilizers...) -jn- [handy--techie--com] wrote:

 [32/52] from: bciceron:rsn:hp at: 26-Sep-2000 16:34


why not a rebol plugin, instead ? so your favorite browser would have a rebol interpreter inside and so the ability to run .r script on the client side...

 [33/52] from: gmassar:dreamsoft at: 26-Sep-2000 15:08


Why not a rebol converter, also? The converter converts any Rebol scripts to some standard language such as ANSI C or ISO Pascal (preferrable). Then use a fast compiler to compile the converted code. You got high-speed executables! Note: we already have JCC and PY2PAS, Java converter to C and Python converter to Pascal (Free Pascal) respectively. Links: http://www.geocities.com/CapeCanaveral/Hangar/4040/jcc.html http://www.spam.ee/~andreie/software/py2pas/english-index.html Geo... [bciceron--rsn--hp--com] wrote:

 [34/52] from: sharriff:aina:med-iq at: 27-Sep-2000 7:23


>can easily be extended to REBOL/View and REBOL/Core should we decide to do >this at some point.
Sounds okay, but whats with the "should we decide to..." I take this as as chance that a wrapper for Core might not see the light of day. All the same it still won´t stop some Rebol guru from implementing something of the sort. The necessity is definately there when one writes applications on which a firm/individual bases its/his/her market value on... Sharriff Aina med.iq information & quality in healthcare AG Gutenbergstr. 42 41564 Kaarst tel.: 02131-3669-0 fax: 02131-3669-599 www.med-iq.de

 [35/52] from: handy:techie at: 28-Sep-2000 0:22


> No flaming from me; just puzzled head-scratching. It's not clear to me > that REBOL and Java are conceptually close enough to be ABLE to compile > REBOL directly into Java bytecode.
Im taking a guess here, but it seems you are thinking at a much higher level than I am. Theoretically conversion from REBOL to bytecode doesnt require any syntactic/semantic resemblance to Java, merely a mapping of REBOL functions to bytecode sequences. Further, this conversion would be somewhat simplified by the fact that the bytecodes are much more finite than the language that it is compiled from (an analogy: c -> RISC assembler), creating less mapping possibilities, making it a simpler conversion process. Im afraid that I am new to both languages and cant adequately go into detail on the points you raised...BUT:
> It would certainly be possible to create a REBOL interpreter written > in Java, but that's not what I understood you to be suggesting (and > my experience with Java suggests that it would run like a pig on > tranquilizers...)
This process would entail roughly the steps I am talking about! ...albiet at the language level, not the bytecode level (but you can always go from lang->bytecode so...) By an interpreter I take it you mean parsing REBOL code and mapping REBOL commands to JAVA commands and executing them? Does this not represent a roughly adequate conversion process? That is, store the commands as opposed to executing them (and maintain a variable's dynamic nature), and then compile the resulting source (it would be shocking source - probably all linear)? Then were home & hosed ... compile to bytecode and to native machine code (if need be - yes i am aware of the design violations this incurrs but ... :) Although I do admit it would be extremely hard to achieve dynamic generation and resultant execution of code ... eg #1 on your list ... hmmm :) AndrewH

 [36/52] from: news:ted:husted at: 27-Sep-2000 11:21


On 9/28/2000 at 12:22 AM [handy--techie--com] wrote:
> By an interpreter I take it you mean parsing REBOL code and mapping
REBOL commands to JAVA commands and executing them? A working example of this product category might be the jPhython project < http://jpython.org/ >. Like REBOL, Python is an interpreted scripting language. jPython does what you might expect, interpret Python code and spit out bytecodes to the JVM, much like cPython would interpret Python and spit machine code to the processor. There's not a snowball's chance of this happening, but if it did, it would mean you could encapsulate REBOL scripts within Java programs. Of course, there may be performance trade-offs, since many JVM's are pokey. Using a high-performance Java configuration, people have matched benchmarks between jPython and cPython (the conventional C implementation). Though, in practice, jPhython is said to be 2.5x slower than the mature cPython compiler. -Ted.

 [37/52] from: petr:krenzelok:trz:cz at: 27-Sep-2000 18:22


----- Original Message ----- From: <[news--ted--husted--com]> To: <[list--rebol--com]> Sent: Wednesday, September 27, 2000 5:21 PM Subject: [REBOL] Compiler for Rebol ? Re:(13)
> On 9/28/2000 at 12:22 AM [handy--techie--com] wrote: > > By an interpreter I take it you mean parsing REBOL code and mapping
<<quoted lines omitted: 12>>
> implementation). Though, in practice, jPhython is said to be 2.5x > slower than the mature cPython compiler.
You will have the smallest jvm with Tao (read some reviews at www.amigasdk.com), and if REBOL/View will run with tao, you run with Java :-) ... -pekr-

 [38/52] from: joel:neely:fedex at: 27-Sep-2000 16:58


Hi, Andrew! [handy--techie--com] wrote:
> > No flaming from me; just puzzled head-scratching. It's not clear to me > > that REBOL and Java are conceptually close enough to be ABLE to compile
<<quoted lines omitted: 4>>
> syntactic/semantic resemblance to Java, merely a mapping of REBOL > functions to bytecode sequences.
I'm sorry, but I must disagree. The JVM and its bytecode were specifically designed for the Java language; many of their features are directly related to requirements, features, and concepts of the Java language. By the same token, concepts NOT part of the Java world-view would be VERY difficult to map directly to JVM bytecode. The "mere" mapping of REBOL functions to JVM bytecode is not very "mere" where REBOL has a concept missing from Java. Let me give just a couple of brief examples: 1) Java uses a class-model style of OO programming, in which one defines a "class" (at compile time) as a kind of factory or classification entity, then creates objects (at run time) by asking the class to construct an "instance" of itself. REBOL uses neither the class/instance distinction nor the compile-time/run-time distinction. 2) Java draws a sharp distinction between code and data. REBOL, as a pure von Neumann language, refuses to recognize that distinction. It is trivial to write REBOL code that modifies itself, or that creates a new function (or just a block) at run-time, and subsequently evaluates/executes that newly constructed expression. I know of no reasonable mechanism in the JVM that allows running JVM bytecodes to manufacture new content for the runtime constant pool (which is where symbolic references to classes, methods, method signatures, etc. are stored). An example of an unreasonable mechanism would be for the running code to compose an entirely new class file on the fly, then invoke the class loader on that new class file. I believe the overhead of such an approach would be intolerably high for any practical uses. 3) Java is a strongly-typed language. JVM bytecodes for such common actions as comparing two values depend on advance (i.e., compile-time) knowledge of the types of the values being compared. Different opcodes are used for comparing two integers than for comparing two doubles, for example. Also, invoking a Java method (e.g., via the INVOKEVIRTUAL opcode) requires a reference to the constant pool which provides a method signature (which includes identification of the types of all arguments). REBOL, by contrast, can punt on the entire issue of function argument types, leaving that issue to be handled implicitly by each operator or explicitly by the high-level code. Based on the above (among other issues), the REBOL code: block1: [a: 1 b: does [print a] z: func [x] [a < x]] block2: [a: 2.3 c: does [print ["fee has" a]]] foo: make object! block1 fee: make foo block2 fum: make object! append copy block1 [ z: func [x] [either number? x [a > x] [false]] ] poses a number of significant challenges to any attempt to render it into equivalent JVM bytecode.
> Further, this conversion would be somewhat simplified by the fact that > the bytecodes are much more finite than the language that it is compiled > from (an analogy: c -> RISC assembler), creating less mapping > possibilities, making it a simpler conversion process. >
I don't understand this sentence at all. Bytecodes typically deal with more fine-grained, operationally oriented concepts than high-level programming languages. The translation process is only "a simpler conversion" (than compilation to object code for some physical computer?) if the defining concepts of the source language and the byte code are nicely aligned.
> Im afraid that I am new to both languages and cant adequately go into > detail on the points you raised...BUT:
<<quoted lines omitted: 5>>
> ...albiet at the language level, not the bytecode level (but you can > always go from lang->bytecode so...)
Different concepts.
> By an interpreter I take it you mean parsing REBOL code and mapping > REBOL commands to JAVA commands and executing them? >
No. The distinction I'm drawing is between a) Writing a compiler (in whatever lanaguage -- that's irrelevant) that reads REBOL source code and produces standard Java class files which can be executed using a standard JVM. That's I was discussing in the first section above. b) Writing a REBOL intepreter IN Java -- i.e., a Java program that reads REBOL source code, parses and analyzes it, and then performs the actions specified by that REBOL code. Those are VERY different. And, IMHO, the first would be extremely difficult (if not totally infeasible), while the second would likely be too slow for any realistic use. -jn- -- ; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677 REBOL [] print to-string debase/64 decompress #{ 789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}

 [39/52] from: sharriff:aina:med-iq at: 28-Sep-2000 10:08


Just when I thought my problems were solved..sorry to bother you guys again [ admin [ name "Sharriff Aina" password "gong" email [sharriff--aina--med-iq--de] dept "Administration" view "yes" ] sharriff [ name "Sharriff Aina" password "jungle" email [sharriff--aina--med-iq--de] dept "Administration" view "yes" ] ] a "SELECT" or "FIND" always results in a " NONE" how do I iterate? the path test-path: admin/name for example works. I would to be able to search the database given the first name (login name) of the user with a function... Thanks and much appreciation for your help I´ll get the hang of this one day, this is my second REBOL week! Sharriff Aina med.iq information & quality in healthcare AG

 [40/52] from: joel:neely:fedex at: 28-Sep-2000 7:07


Well, Sharriff, it depends on what you want to select... Using cut-n-paste from your original note:
>> foo: [
[ admin [ [ name "Sharriff Aina" [ password "gong" [ email [sharriff--aina--med-iq--de] [ dept "Administration" [ view "yes" [ ] [ [ sharriff [ [ name "Sharriff Aina" [ password "jungle" [ email [sharriff--aina--med-iq--de] [ dept "Administration" [ view "yes" [ ] [ ] == [ admin [ name "Sharriff Aina" password "gong" email [sharriff--aina--med-iq--de] dept "Admini...
>> select foo 'admin
== [ name "Sharriff Aina" password "gong" email [sharriff--aina--med-iq--de] dept "Administration" view "yes" ]
>> select foo "admin"
== none
>> select foo admin
** Script Error: admin has no value. ** Where: select foo admin Note that all of your "key" values are of type word! and NOT of type string! which means you must use a literal word or an expression that evaluates to a value of type word! in order to get a match. OTOH, if you want to search by name, you can either write a function to search the nested blocks, as in
>> searchname: func [who [string!] /local k v] [
[ foreach [k v] foo [ [ if v/name = who [return v] [ ] [ ]
>> searchname "Sharriff Aina"
== [ name "Sharriff Aina" password "gong" email [sharriff--aina--med-iq--de] dept "Administration" view "yes" ] OTOH, (wait a minute... I don't have three hands! Can somebody give me a hand? ;-) if you're going to do lots of searching in that data structure, it's worthwhile to pre-build another data structure that can serve as an index or cross-reference to the original one:
>> buildxref: func [/local xref k v] [
[ xref: copy [] [ foreach [k v] foo [ [ append xref v/name [ append/only xref v [ ] [ xref [ ]
>> fum: buildxref
== ["Sharriff Aina" [ name "Sharriff Aina" password "gong" email [sharriff--aina--med-iq--de] dept "A...
>> select fum "Sharriff Aina"
== [ name "Sharriff Aina" password "gong" email [sharriff--aina--med-iq--de] dept "Administration" view "yes" ] Modifying either of the above to return both the key and value from the ORIGINAL block (e.g., getting back BOTH the key 'admin and the block of associated data), is a minor tweak that is left to the reader. (That's academicspeak for "I don't have time to type it right now." but feel free to ask if you want any followup! ;-) -jn- [Sharriff--Aina--med-iq--de] wrote:

 [41/52] from: sharriff:aina:med-iq at: 28-Sep-2000 14:21


Thanks Jeff!! one question: the "local" value "k", what is it piroüose exactly , its not beineg breferenced at all
>> buildxref: func [/local xref k v] [
[ xref: copy [] [ foreach [k v] foo [ [ append xref v/name [ append/only xref v [ ] [ xref [ ] Sharriff Aina med.iq information & quality in healthcare AG Gutenbergstr. 42 41564 Kaarst tel.: 02131-3669-0 fax: 02131-3669-599 www.med-iq.de

 [42/52] from: joel:neely:fedex at: 28-Sep-2000 14:34


[Sharriff--Aina--med-iq--de] wrote:
> Thanks Jeff!! one question: > > the "local" value "k", what is it piroüose exactly , its not beineg > breferenced at all >
Hey, I did say I'd left something as an exercise! ;-)
> >> buildxref: func [/local xref k v] [ > [ xref: copy []
<<quoted lines omitted: 4>>
> [ xref > [ ]
If the second argument of foreach is a list of words, then they take consecutive values from the block that is the second argument.
>> foo: [1 "a" 2 "b" 3 "c" 4 "d"]
== [1 "a" 2 "b" 3 "c" 4 "d"]
>> foreach [n s] foo [print s]
a b c d
>> foreach [n s] foo [print n]
1 2 3 4
>> foreach [n s] foo [print [n "->" s]]
1 -> a 2 -> b 3 -> c 4 -> d
>>
So, all I was saying in buildxref was "Walk through foo , treating it as a collection of pairs. Call the left-hand element k and the right-hand element v while looking at each pair. Now, here's what to do with each pair..." It just happens that the simplified version if cross-referencing I showed in that example didn't use the left-hand element. There are other ways to skin this cat. For example, using forskip as illustrated by:
>> skipfoo: next foo
== ["a" 2 "b" 3 "c" 4 "d"]
>> forskip skipfoo 2 [print first skipfoo]
a b c d == false
>> skipfoo: foo
== [1 "a" 2 "b" 3 "c" 4 "d"]
>> forskip skipfoo 2 [print first skipfoo]
1 2 3 4 == false
>> skipfoo: foo
== [1 "a" 2 "b" 3 "c" 4 "d"]
>> forskip skipfoo 2 [print [first skipfoo "->" second skipfoo]]
1 -> a 2 -> b 3 -> c 4 -> d == false
>>
Both of these approaches can be used with groupings of more then two elements at a time. For instance, if I had a block containing ID#, name, and phone number for a bunch of employees (I'll not bother to make up sample data for this one), one could list all of the names by saying either (*WARNING* *UNTESTED CODE FRAGMENT*) foreach [emp-id emp-name emp-phone] emp-data-block [ print emp-name ] or emp-temp-block: next emp-data-block forskip emp-temp-block 3 [print first emp-temp-block] or (a TOTALLY UNSATISFACTORY solution, in my opinion) emp-data-block: next emp-data-block forskip emp-data-block 3 [print first emp-data-block] emp-data-block: head emp-data-block The first of these three (at least to my eye) seems to do the best job of making clear that I'm dealing with emp-data-block as a collection of triples, and making clear exactly what I'm doing with (what parts of) each triple. -jn- PS: Since I've already blabbered on for this long, I might as well include one solution to the open issue I raised in the earlier post in this thread -- creating an index/crossreference to your original block that lets me start with a name and get at both the key and value block from the original data structure: == false
>> foo: [
[ admin [ [ name "Sharriff Aina" [ password "gong" [ email [sharriff--aina--med-iq--de] [ dept "Administration" [ view "yes" [ ] [ [ sharriff [ [ name "Sharriff Aina" [ password "jungle" [ email [sharriff--aina--med-iq--de] [ dept "Administration" [ view "yes" [ ] [ ] == [ admin [ name "Sharriff Aina" password "gong" email [sharriff--aina--med-iq--de] dept "Admini...
>> buildxref: func [orig [block!] /local xref k v] [
[ xref: copy [] [ foreach [k v] orig [ [ append xref v/name [ append/only xref reduce [k v] [ ] [ xref [ ]
>> fum: buildxref foo
== ["Sharriff Aina" [ admin [ name "Sharriff Aina" password "gong" email sharriff.ain...
>> first select fum "Sharriff Aina"
== admin This version uses both the key and value elements of each pair. Of course, I can't let this drop without assigning more homework (old teaching habits die hard ;-), so let's notice that the name "Sharriff Aina" occurs more than once in your original data. Wouldn't it be nice to have a version of buildxref that made a crossreference structure that paired each name with a block of key/value pairs, for all entries in the original data where the name appeared? -- ; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677 REBOL [] print to-string debase decompress #{ 789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}

 [43/52] from: sharriff:aina:med-iq at: 28-Sep-2000 15:58


..Whoa! you laid it down so nicely it seems painfully simple, I really have to RTFM, not once but "LOOP 5" times ;-) I would do some reading now on all what you´ve explained to me..sorry to have been a bother to you. Thanks Jeff ..uhm Mr. Sassenrath? if you´re reading this list : someone said somewhere that REBOL was addictive, he was right...PLEASE make an EXEC function free for CORE ( I think everyone on this list agrees with me? ) Sharriff Aina med.iq information & quality in healthcare AG

 [44/52] from: jhagman:infa:abo:fi at: 28-Sep-2000 19:14


Quoting [joel--neely--fedex--com] ([joel--neely--fedex--com]):
> [jhagman--infa--abo--fi] wrote: > >
<<quoted lines omitted: 12>>
> public beta of /View and the current rlse of /Core blew up instead > of running.
Yes, that's the demo effect! :) I hope you tested rebol on that machine _before_ the demo...
> I didn't report it at the time because the box was > Debian Unstable, and assumed that maybe the guy who set it up was > just a little too close to the edge. > > Since then, I've seen traffic on this list indicating that others have > had problems with REBOL on Debian, so perhaps my experience wasn't so > unique or box-owner-dependent after all???
Yes, problem was the guy running the box, not Debian not even it's unstableness. The root of the problem lies in rebol using an _ancient_ library called termcap. Debian does not have this library in it's normal distribution but in _oldlibs_ as it is very old it is compiled against libc5. As other libraries and rebol are compiled against libc6 and those two don't mix the crash occurs. The guy running the box just has not removed the old libtermcap. He surely has no programs depending on it anymore. The workaround is to remove the libtermcap and make link from libncurses to libtermcap. So, it is not Debian's fault that the guy wanted to keep an old libc5 library installed. Sure Debian is somewhat harder to install than RedHat. But it has some other virtues (atleast for power users and opensource enthusiasts). And for my part, no I was not up for the task either and had libtermcap installed once, but that has been long gone. I surely wondered about the problem for a long time. I would suggest REBOL to include a warning to the readme on this. It seems that a lot of people have debian installed with the libtermcap. Yours, Jussi -- Jussi Hagman CS in Åbo Akademi University Studentbyn 4 D 33 [juhagman--abo--fi] 20540 Åbo [jhagman--infa--abo--fi] Finland

 [45/52] from: holger:rebol at: 28-Sep-2000 10:43


On Thu, Sep 28, 2000 at 07:14:53PM +0300, [jhagman--infa--abo--fi] wrote:
> And for my part, no I was not up for the task either and had > libtermcap installed once, but that has been long gone. I surely > wondered about the problem for a long time. I would suggest REBOL to > include a warning to the readme on this. It seems that a lot of people > have debian installed with the libtermcap.
The new experimental versions of REBOL/Linux/x86 come with libtermcap statically linked, so there should be no more conflicts with libc5/6. -- Holger Kruse [holger--rebol--com]

 [46/52] from: larry:ecotope at: 28-Sep-2000 12:10


Hi Joel Just a small clarification. You wrote:
>> searchname: func [who [string!] /local k v] [
[ foreach [k v] foo [ [ if v/name = who [return v] [ ] [ ] Actually the declaration of k and v as local vars to the searchname function is unnecessary as in your example they are never used. The foreach function binds the words in it's first arg (also k and v in your example) as local to it's own context. The outer k and v are unused. Here is a short example:
>> f: func [/local k][
[ k: 1 [ foreach [k]["a" "b"][print k] [ print k [ ]
>> f
a b 1
>>
Cheers -Larry

 [47/52] from: joel:neely:fedex at: 28-Sep-2000 19:25


Thanks, Larry! You're absolutely right... I ran into this a while back in the context of the following kind of thing: something: [print x] foreach x some-block [do something] but the knowledge hasn't made it from my memory to my typing fingers! ;-) -jn- [larry--ecotope--com] wrote:
> Hi Joel > Just a small clarification. You wrote:
<<quoted lines omitted: 19>>
> Cheers > -Larry
-- ; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677 REBOL [] print to-string debase decompress #{ 789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}

 [48/52] from: jhagman:infa:abo:fi at: 1-Oct-2000 21:11


Quoting [holger--rebol--com] ([holger--rebol--com]):
> The new experimental versions of REBOL/Linux/x86 come with libtermcap > statically linked, so there should be no more conflicts with libc5/6.
Great! -- Jussi Hagman CS in Åbo Akademi University Studentbyn 4 D 33 [juhagman--abo--fi] 20540 Åbo [jhagman--infa--abo--fi] Finland

 [49/52] from: chris:double:tab at: 2-Oct-2000 9:40


> Those are VERY different. And, IMHO, the first would be extremely > difficult (if not totally infeasible), while the second would likely > be too slow for any realistic use.
Have you seen Kawa? The scheme compiler that compiles to JVM and executes the byte code on the fly [1]. It would seem to face the same sorts of problems as a REBOL-on-JVM would face and it works quite nicely. [1] http://www.gnu.org/software/kawa/kawa.html Chris. -- http://www.double.co.nz/dylan

 [50/52] from: joel:neely:fedex at: 1-Oct-2000 21:45


[chris--double--tab--co--nz] wrote:
> > Those are VERY different. And, IMHO, the first would be extremely > > difficult (if not totally infeasible), while the second would likely > > be too slow for any realistic use. > > Have you seen Kawa? The scheme compiler that compiles to JVM and > executes the byte code on the fly [1]. >
Not before your post. Thanks! I've been looking at their site since receiving the URL you provided. I'm quite impressed with what they've done.
> It would seem to face the same sorts of problems as a REBOL-on-JVM > would face and it works quite nicely. >
I guess it depends on one's definition of "quite nicely". My own definition of "nicely-working" REBOL-on-JVM is quite simple (and quite strict!): it must be totally equivalent in functionality to REBOL as supplied by RT. One should be able to pick up any working REBOL script and compile/execute it in the alternate environment with no changes and no feature unsupported. Bear in mind that there are already many versions of LISP/Scheme. I suspect that the shock to the LISP/Scheme community of stepping from N version to N+1 versions would be smaller than the shock to the REBOL community of stepping from 1 version to 2. Further, there is already a large body of literature using the Scheme language (including the seminal SICP). Having more options for running programs in a widely-publicized language is a good thing, but that's not the most burning issue for REBOL, IMHO. In addition, I view Scheme as a significantly simpler language than REBOL. I should also add at this point that the "internals" of Scheme are FAR better documented than what is currently available for REBOL -- regardless of whether this is because of RT policy, trade secrets, work-in-progress issues, or just the fact that Carl and the other folks at RT deserve at least three or four hours of sleep a week! ;-) Finally, I'm not challenging the theoretical posibility of doing REBOL on a JVM, but I have serious questions about how practical it would be, depending on one's objectives.
> [1] http://www.gnu.org/software/kawa/kawa.html >
Having looked briefly through that site, I am impressed by the work that's been done thus far, but it appears to fall short of the (admittedly hard-nosed) criterion I stated above. Consider the partial list of exceptions and caveats quoted from the site above: Also, call-with-current-continuation is only "upwards" (?). I.e. once a continuation has been exited, it cannot be invoked. These restricted continuations can be used to implement catch/throw (such as the examples in R4RS), but not co-routines or backtracking. Here, a feature of the language can't be used in Kawa to do some things it can do in standard Scheme. Kawa now does general tail-call elimination, but only if you use the flag --full-tail-calls. (Currently, the eval function itself is not fully tail-recursive, in violation of R5RS.) The --full-tail-calls flag is not on by default, partly because it is noticably slower (though I have not measured how much), and partly I think it is more useful for Kawa to be compilatible with standard Java calling conventions and tools... I assume that "compatible" was meant by the mangled word in the next- to-last line; if so, compatibility with Jave was deemed useful enough to influence the default behavior of this implementation. Even without --full-tail-calls, if the compiler can prove that the procedure being called is the current function, then the tail call will be replaced by a jump. This means the procedure must be defined using a letrec, not a define (because the compiler does not know if someone might re-define a global definition), and there must be no assignments (using set!) to the procedure binding. Note the parenthesized remark that "the compiler does not know if someone might re-define a global definition", a perfectly reasonable thing to do in REBOL. If you define a macro with defmacro, you (currently) cannot use the macro in the same compilation as the definition. A fairly severe restriction, IMHO. The current Kawa compiler is rather simple-minded, and in many places only allows simple types that the compiler can evaluate at compile-time. More specifically, it only allows simple type names that map to primitive Java types or java classes. Another example of a Java-oriented language compromise. This next one needs some explanation. The rules for valid names in Scheme are different (and much more liberal) than the rules for valid names in Java. Kawa "mangles" (their word, not mine) Scheme names into the more limited options allowed by Java. With that background: Note that this mapping may map different Scheme names to the same Java name. For example `string?', `String?', `is-string', `is-String', and `isString' are all mapped to the same Java identifier `isString'. Code that uses such "Java-clashing" names is not supported. In other words, you must know what names are legal in Java and how Kawa maps Scheme names to that more restricted set, or risk having multiple names that end up the same. If so, tough luck. The behavior of interpreted code and compiled code is not indentical, though you should get the same result either way unless you have designed the classes rather strangely. In contrast to the previous point, no explanation for "rather strangely" is given. Thus, there's no guarantee that you won't write "strange" code which behaves inconsistently. Let me be VERY clear. I'm impressed with what the Kawa team has done, and do not intend my comments to reflect negatively on their accomplishments. What I am trying to point out, however, is that a quick perusal of their web site reveals that using Kawa is not SIMPLY a matter of taking any working Scheme program and dropping it into their compiler. Even if it were feasible to build a REBOL-onto-JVM compiler of comparable quality to Kawa, I wonder whether the brainpower might be more profitably spent on other REBOL promotion and support issues: documentation, more tutorials, building a "standard library" of widely-needed and reusable objects/functions, etc. Thanks for the very interesting link! I'll plan to read more on what they're doing with Kawa. -jn-

 [51/52] from: joel:neely:fedex at: 1-Oct-2000 22:38


Let me clarify a previous statement that probably was misleading: [joel--neely--fedex--com] wrote:
> 2) Java draws a sharp distinction between code and data. REBOL, > as a pure von Neumann language, refuses to recognize that
<<quoted lines omitted: 10>>
> overhead of such an approach would be intolerably high for any > practical uses.
It's not actually necessary to write the class file to disk and load it back from disk. A ClassLoader can take bytecode from an array in memory. That detail wasn't my main point -- which was that manufacturing new classes on the fly would be a terribly inefficient way to handle the REBOL concept florp: make object! [ ; etc... ] glompfh: make florp [ ; more etc... ] However, I don't want to risk making bogus arguments, in fact or appearance. -jn- -- ; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677 REBOL [] print to-string debase/64 decompress #{ 789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}

 [52/52] from: chris:double:tab at: 3-Oct-2000 8:16


> Even if it were feasible to build a REBOL-onto-JVM compiler of > comparable quality to Kawa, I wonder whether the brainpower might be > more profitably spent on other REBOL promotion and support issues: > documentation, more tutorials, building a "standard library" of > widely-needed and reusable objects/functions, etc.
Personally I agree. I thing it would be better to spend time on using/developing the current REBOL than building another. One problem with two not-quite-the-same implementations is having to keep them in sync with each other. Similar to the JVM is the microsoft .NET platform. Many languages have been ported to .NET but due to difficulties most of the languages have had to have subtle changes or not implement the more difficult parts of the languages (like call/cc for example).
> Thanks for the very interesting link! I'll plan to read more on what > they're doing with Kawa.
You're welcome! Cheers, Chris.

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