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

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