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
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 24, 2000 7:24 PM
Subject: [REBOL] Compiler for Rebol ? Re:(7)
> [EMAIL PROTECTED] 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-
>
>
>
