Hi list,
Joel wrote:
> 3) Using an "economic" perspective, one (oversimplified!) conclusion
> I reach from Ladislav's work is to say the following:
>
> To use REBOL control structures reliably, one MUST first
> understand the significance of copying, deep copying, function
> definition, and contexts. I worry about whether this cost is
> so high as to prove prohibitive to entry-level REBOL users.
>
I don't think so. If I consider Rebol control structures like While, Either,
If, Foreach, Loop,..., everything seems to be OK (I didn't include For just
because it still contains a series bug I discovered/patched, but that bug
has no influence on its execution in normal cases - i.e. when you don't use
it to traverse a series).
If anybody prefers a WYSIWYG Code, (s)he shall use improved Use I suggested
in recursive functions, avoid to use Forskip and Repeat recursively (or
patch them accordingly), be careful when using Make Object! recursively (or
patch it too). The problem is, that sometimes you can't tell for sure, if a
code isn't being executed recursively. In that case you should use the safe
strategy.
Holger wrote:
First of all, I consider most of what Ladislav mentioned to be the result of
"switching pain", difficulties when switching from one language to another
one, and adjusting to a different way of thinking. It is easy to keep using
paradigms that are common in C or Pascal when switching to REBOL (paradigms
such as "code", "variables", "execution" etc.), instead of switching to the
REBOL way of thinking. This sometimes gets people into trouble. From the
terminology Ladislav used I suspect that this may be the case here, too. See
below...
Ladislav:
Not at all! My goal is to show the list members, and to myself, the
difference between WYSIWYG and SM Rebol Code and to show you how and why to
choose the one that you prefer. To make myself clear, I prefer the WYSIWYG
Rebol Code, although I am not trying to write the definition of the notion,
because it seems to me, that the examples are the best means to demonstrate
the sense of the notion. (In the case you didn't notice, this is only a way
how to hide, that I am not able to put together a definition right now ;-)
Holger:
Ladislav suggests deep copying everything. I don't think that is necessary
or
appropriate (from a performance point of view).
Ladislav:
I am afraid I didn't succeed to demonstrate (e.g. in Code3), that deep
copying may be a nonsense sometimes, as long, as you don't know, what you
are doing :-(
Re code vs. data issue: I, being a programmer, recall, that every piece of
code I wrote in any programming language, was written as data for
appropriate program I used at that time...
Back to Part #3:
*WYSIWYG rule*: Don't try to modify anything that is at the same time being
evaluated as Rebol code, otherwise be prepared to get a WYSINWYG/SM Code.
WYSIWYG examples:
First, I will try to show you how to convert:
a: [append a [+ 1] 1]
do a
to a WYSIWYG Rebol Code. Here the problem is, that A is being modified at
the same time A is being Done, which is what I mean by SMC. That fact really
causes a strange result, as you might have seen in Part#1. The converted
code:
; the first modification preserves just the line below and is almost
unnecessary
; (as long, as the line isn't reused)
a: copy [append a [+ 1] 1]
; the next modification is here to make sure we don't modify A and Do A at
the same time
do copy a
The result is obvious, the above code works as expected!
Now let's WYSIWYG-ize Code6:
code6: [1 (remove code6) 2]
do code6
Everybody can guess, what I would suggest:
code13: copy [1 (remove code13) 2]
do copy code13
== 2
At last!
A more real-life example:
counter: does [
0
change second :counter (first second :counter) + 1
first second :counter
]
>> counter
== 1
>> counter
== 2
>> counter
== 3
>> counter
== 4
>> counter
== 5
>> counter
== 6
>> counter
== 7
>> counter
== 8
The above code does something useful. There is not an easy way to convert
that to WYSIWYG, because the GC bug could mess things. The most obvious is:
counter-memory: 0
counter: does [counter-memory: counter-memory + 1]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
