Is Rebol dynamic?
[1/11] from: lmecir:mbox:vol:cz at: 28-Nov-2002 10:54
1) Rebol is dynamic. Let's try the following code:
>> block1: [print 1 (block1/5: 3) print 2]
== [print 1 (block1/5: 3) print 2]
>> do block1
1
3
We succeeded to change BLOCK1 during its execution!
2) Rebol is dynamic only to some extent:
>> block2: [print 1 (insert tail block2 1 block2/5: 3) print 2]
== [print 1 (insert tail block2 1 block2/5: 3) print 2]
>> do block2
1
2
Now the change isn't observable as before!
Generally spoken:
We are able to change a block during its execution, but the effect of such a
change isn't defined.
-L
[2/11] from: rotenca:telvia:it at: 28-Nov-2002 14:39
Hi Ladislav,
I remember Holger saying that a rebol block must not be changed during
execution.
I think that it is safe to change 1 or more elements of block during
execution, but not to insert/remove any item.
Can changing (not inserting) be a safe programming style for future releases?
---
Ciao
Romano
[3/11] from: lmecir:mbox:vol:cz at: 28-Nov-2002 15:46
Hi Romano,
----- Original Message -----
From: "Romano Paolo Tenca"
> I remember Holger saying that a rebol block must not be changed during
> execution.
>
> I think that it is safe to change 1 or more elements of block during
> execution, but not to insert/remove any item.
>
> Can changing (not inserting) be a safe programming style for future
releases?
> ---
> Ciao
> Romano
Holger's advice is OK. Can we change the elements of an executed block? This
seems to work "expectedly":
>> a: func [x] [type? get/any 'x]
>> b: func [x] [type? get/any 'x]
>> block: [a (block/1: 'b 12)]
== [a (block/1: 'b 12)]
>> do block
== integer!
How about this?
>> block: [a: (block/1: first [b:] 12)]
== [a: (block/1: first [b:] 12)]
>> do block
== 12
>> b
== 12
Ciao
-L
[4/11] from: al:bri:xtra at: 29-Nov-2002 11:57
Romano wrote:
> I remember Holger saying that a rebol block must not be changed during execution.
>
> I think that it is safe to change 1 or more elements of block during execution, but
not to insert/remove any item.
>
> Can changing (not inserting) be a safe programming style for future releases?
I think it's probably due to Rebol resizing the block? Perhaps if the block was allocated
enough space in the first place, then the insert could work.
Andrew Martin
[5/11] from: lmecir:mbox:vol:cz at: 29-Nov-2002 9:30
Yes, Andrew, you have got it right.
> > I think that it is safe to change 1 or more elements of block during
execution, but not to insert/remove any item.
> >
> > Can changing (not inserting) be a safe programming style for future
releases?
> I think it's probably due to Rebol resizing the block? Perhaps if the
block was allocated enough space in the first place, then the insert could
work.
>
> Andrew Martin
If we try the same example as before, we will see:
>> block2: make block! 8
== []
>> append block2 [print 1 (insert tail block2 1 block2/5: 3) print 2]
== [print 1 (insert tail block2 1 block2/5: 3) print 2]
>> do block2
1
3
BTW, if we preallocated less than 8, the behaviour would differ, although
the final block size is 6 elements...
Nevertheless, I think, that I proved, that neither inserts nor changes are
safe. If you want to see an unsafe change, look at this:
block3: [a: (block3/1: first [/a] 1)]
do block3
-L
[6/11] from: rotenca:telvia:it at: 29-Nov-2002 20:46
Hi Ladislav
> How about this?
> >> block: [a: (block/1: first [b:] 12)]
<<quoted lines omitted: 3>>
> >> b
> == 12
Surprise! Also because:
>> a: "12" b: 1 do block: [a/1: (block/1: first [b:] #"E")]
== "E2"
>> b
==1
---
Ciao
Romano
[7/11] from: rotenca:telvia:it at: 29-Nov-2002 21:07
Hi Ladislav,
> block3: [a: (block3/1: first [/a] 1)]
> do block3
I think that the failure is the set bug with unbound word.
Playing with fire:
How to set a get-word preserving binding?
>> c: 2 do block3: [a: (block3/1: first [c] 1)] c
== 1
---
Ciao
Romano
[8/11] from: lmecir:mbox:vol:cz at: 30-Nov-2002 12:00
Hi Romano et all,
> > How about this?
> >
<<quoted lines omitted: 9>>
> >> b
> ==1
I think, that the last word about precedence and evaluation wasn't said in
Rebol. Some transparency/unification/straightening/debugging can still have
some use.
[9/11] from: lmecir:mbox:vol:cz at: 30-Nov-2002 12:11
Hi Romano,
----- Original Message -----
From: "Romano Paolo Tenca"
> > block3: [a: (block3/1: first [/a] 1)]
> > do block3
>
> I think that the failure is the set bug with unbound word.
You are right in this case. But I think, that more examples proving, that
this behaviour is unsafe, can be found.
> Playing with fire:
>
> How to set a get-word preserving binding?
>
> >> c: 2 do block3: [a: (block3/1: first [c] 1)] c
> == 1
If we just want to set a get-word, we can:
set first [:c] 11
-L
[10/11] from: rotenca::telvia::it at: 30-Nov-2002 14:12
Hi Ladislav,
> If we just want to set a get-word, we can:
>
> set first [:c] 11
Uh! I did never notice it.
set [c:] 1
fails also with 1.2.8.
I can't explain it because:
set first [c:] 1
works fine.
---
Ciao
Romano
[11/11] from: lmecir:mbox:vol:cz at: 30-Nov-2002 17:27
Hi Romano,
> > If we just want to set a get-word, we can:
> >
> > set first [:c] 11
>
> Uh! I did never notice it.
>
> set [c:] 1
>
> fails also with 1.2.8.
vice versa, I never noticed the failure, it looks like a bug to me, it may
be worth to send it to feedback.
-L
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted