[REBOL] Re: What language am I looking for?
From: joel:neely:fedex at: 17-May-2001 7:24
Hi, Petr,
My admiration for your stamina! ;-)
Petr Krenzelok wrote:
> Ladislav thinks Rebol could become much faster, if certain
> things are implemented (see his rep - don't remember url
> now ...)
>
> > 0) Interpret the language. Accept the reduced execution
> > speed as the cost of flexibility.
>
> that's ok, ... look I am no expert on languages, but reading
> Ladislav's doc I came to conclusion, that sometimes we could
> accept some small language limitations gaining us much more
> execution speed. After all - the proposed changes are not
> drastic imo ...
>
I're read Ladislav's REP. I simply haven't persuaded myself
(yet?) that the overall effect of his proposals would be a
substantial improvement in performance for the majority of
REBOL programs.
> that's why Ladislav suggest immutable block representation.
> If you know, that your block will not be modified during
> the execution phase, you could compile it then - this
> partial compilation could bring us some nice speed increase
> ... well, as I said - just my theory without any experience :-)
>
Sorry, but I disagree with the conclusion -- although after
re-reading my original paragraph I accept full blame that my
wording probably was misleading.
IMHO, block immutability has more to do with notational and
correctness issues ("principle of least surprise", avoidance
of subtle bugs, eliminating tricky cases that can "trip" the
interpreter, etc.) than performance. The performance issues
I *meant* to be describing require nothing more than block
construction and evaluation. Modifying or eliminating *these*
would have a *drastic* effect on REBOL notation.
Consider the following fragment:
>> showall: func [b [block!] /local c] [
[ foreach item b [
[ c: compose/deep [print [(mold :item) "=" (item)]]
[ do c
[ ]
[ ]
>> tot: 17
== 17
>> obj: instantiate [a: 1 b: 2 c: 3 d: 4 e: "done!"]
>> showall [tot obj/a obj/b obj/e]
tot = 17
obj/a = 1
obj/b = 2
obj/e = done!
>>
The value of C is not being mutated, but each pass through
the loop constructs a new block and then DOes that block.
Therefore, this bit of code would require recompilation of
C's (new) value on each pass.
> Just a sidenote: I like Tao's aproach here - translated
> and compiled into machine independent code (Virtual
> Processor code). During ICOA days Amigans looked at slim
> binaries principles too.
>
That idea has been around long enough to have as much grey
hair as I do! ;-) A partial list of its heritage includes
UNCOL, SNOBOL, UCSD Pascal, and Java. Clearly some people
think it works for their Language Of Choice. Perhaps for
REBOL also?
> > Accept the fact that net speed
> > over some programs (e.g., those that keep manipulating
> > and evaluating the same block(s) repeatedly) may not
> > be much of a gain -- if any -- over plain interpretation.
> >
> > (Note that "data-like mutation of the block" includes any
> > changes to its content, the content of its content, etc.
> > Such transitive closures are non-trival to compute! I'll
> > not pursue this aspect further, at least for now; I just
> > wanted to point out that there are *HAIRY* details.)
> >
(My same apologies for the misleading wording. I should hav
said "data-like construction of a block" instead.)
> ah, you are probably right here. But then it's up to app
> designer to construct block the way compilation will make
> sense for him/her if he/she wants to use it :-)
>
Sure. But this increases the list of rules and heuristics
the developer must bear in mind while constructing the block.
I submit that this constitues an increase in complexity (or
reduction in simplicity, however we want to word it).
-jn-
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
