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

[REBOL] Re: Bug! in assignment to date! values with stacked set-path values

From: lmecir:mbox:vol:cz at: 13-Nov-2002 18:16

Hi Romano, I tried to tell, that the behaviour was caused by the fact, that the whole thing was only a hack. The hack was most probably not well thought out and the same hack could have been made for integers and has been made for issues.
> It seems to me that the mutation hack is not enough to explain this. The > problem is that all the value are pre-fetched before the first assign
> else with or without mutation the result should be right. Instead, the > pre-fetch works only with mutable values. The bug is prefetch the value of > set-path.
You are right. The behaviour can be corrected, although that might influence the speed of the interpreter...
> Neither parens can correct the problem. > Look at this: > > >> a: "aaa" probe a/2: (a: "bbb" #"c") a > "aca" > == "bbb" > > As you can see the a/2 continue to refer to the old string "aaa" also when
> parens block has changed the 'a value with "bbb". I can be wrong but i do
> see any mutation hack here. > > --- > Ciao > Romano
Ah, I didn't read your whole post, sorry. This is interesting and it is a proof of the fact, that the whole path business is a hack in Rebol (no surprise). When we are at it, we shall ask RT to change the path business more thoroughly to introduce referential transparency. I am afraid, that this change will affect the way Rebol parser (make block! / load) works, because I would suggest to not treat #"(" and #")" as ordinary delimiters. Instead Rebol should treat them as "forbidden" characters, which aren't allowed to occur in words. Nevertheless, a/(1 + 2) should differ from a / (1 + 2) , where the former can be treated as a path, while the latter as an expression, which divides A by 3. What do you think about the fact, that the difference is small, which may lead to confusions? -L